Begriffe: Rate Limit, Quota und Throttling

Die drei Begriffe werden oft vermischt, beschreiben aber unterschiedliche Aspekte derselben Idee, nämlich der Begrenzung des Anfragevolumens.

  • Rate Limit: die maximale Anzahl an Anfragen in einem kurzen, gleitenden Zeitfenster, typischerweise pro Sekunde oder pro Minute (z. B. 100 Anfragen/Minute). Es schützt vor Überlast und glättet Lastspitzen.
  • Quota: ein Kontingent über einen längeren Zeitraum, etwa pro Tag oder pro Monat (z. B. 10.000 Anfragen/Tag). Quotas regeln meist fachliche oder kommerzielle Grenzen (Tarifstufen, faire Verteilung) statt akuter Überlast. Der IETF-Entwurf zu RateLimit-Headern definiert eine Quota formal als die einer Partition zugeteilte Kapazität, gemessen in Quota Units innerhalb eines Zeitfensters.
  • Throttling: das tatsächliche Verhalten bei Überschreitung. Der Server kann Anfragen ablehnen (z. B. mit 429), verzögern (Shaping) oder die Verbindung kappen. Throttling ist also die Durchsetzung, Rate Limit und Quota sind die Regeln.

In der Praxis kombiniert man mehrere Stufen, etwa ein kurzes Burst-Limit pro Sekunde, ein Minutenlimit und eine Tagesquota. Der IETF-Entwurf nennt genau dieses Muster als Beispiel für überlagerte Policies, die gemeinsam eine Anfrage betreffen können.

AlgorithmusBurst-VerhaltenSpeicherbedarfTypischer Einsatz
Token BucketBursts bis zur Eimertiefe erlaubtGering (Zähler + Zeitstempel je Partition)API-Gateways, Standardwahl
Leaky Bucket (Queue)Kein Burst, gleichmäßige AusgaberateGering bis mittel (Warteschlange)Traffic Shaping, gleichmäßiger Durchsatz
Fixed WindowBis zu doppeltes Limit an FenstergrenzeSehr gering (ein Zähler je Fenster)Einfache Quotas, unkritische Fälle
Sliding Window (Counter)Glättet Grenzeffekt, nahe am exakten FensterGering (zwei Zähler je Partition)Genauere Limits ohne vollen Log

Rate-Limiting-Algorithmen im Vergleich

Algorithmen: Token Bucket, Leaky Bucket, Fixed und Sliding Window

Ein Rate Limiter braucht einen Zählmechanismus. Vier Verfahren sind verbreitet, sie unterscheiden sich vor allem darin, wie sie kurzzeitige Bursts behandeln.

Token Bucket

Ein Eimer fasst maximal N Token und wird mit konstanter Rate aufgefüllt. Jede Anfrage entnimmt einen Token, ist der Eimer leer, wird die Anfrage abgelehnt. Die durchschnittliche Rate entspricht der Auffüllrate, die Eimertiefe bestimmt die zulässige Burstgröße. Das Verfahren erlaubt also kontrollierte Lastspitzen und ist das in API-Gateways am häufigsten eingesetzte Modell (z. B. setzt Amazon API Gateway Token Bucket mit einem Burst-Parameter ein).

Leaky Bucket

Spiegelbild des Token Bucket. Anfragen laufen in einen Eimer (Warteschlange), der mit fester Rate ausgeläuft, also abgearbeitet wird. Läuft der Eimer über, werden Anfragen verworfen. Als Queue erzwingt Leaky Bucket eine gleichmäßige Ausgaberate (Traffic Shaping), als reiner Meter (Zähler, der mit fester Rate sinkt) ist er mathematisch äquivalent zum Token Bucket.

Fixed Window

Ein einfacher Zähler pro festem Intervall, etwa pro Kalenderminute. Leicht zu implementieren, hat aber das Boundary-Problem: An der Fenstergrenze können bis zu zwei volle Limits unmittelbar aufeinander folgen (Ende des einen, Anfang des nächsten Fensters), wodurch kurzzeitig das Doppelte durchgeht.

Sliding Window

Verfeinert Fixed Window, indem das Fenster mit der Zeit mitwandert. Praktisch üblich ist ein Sliding Window Counter, der den vorherigen und den aktuellen Fensterzähler gewichtet kombiniert. Das glättet den Grenzeffekt bei moderatem Speicherbedarf und kommt einem echten gleitenden Log nahe, ohne jeden Zeitstempel speichern zu müssen.

HTTP-Signalisierung: 429, Retry-After und RateLimit-Header

Bei Überschreitung sollte eine API maschinenlesbar antworten, damit Clients ihr Verhalten anpassen können, statt blind weiter zu pollen.

  • Statuscode: 429 Too Many Requests (RFC 6585) signalisiert, dass der Client in einem Zeitraum zu viele Anfragen gesendet hat. Die Antwort SOLLTE die Bedingung erläutern und KANN einen Retry-After-Header enthalten.
  • Retry-After (RFC 9110): teilt mit, wie lange gewartet werden soll, entweder als delay-seconds (z. B. Retry-After: 120) oder als HTTP-date. Es wird auch bei 503 und 3xx verwendet.

Für das proaktive Mitteilen der verbleibenden Kapazität gibt es lange keinen einheitlichen Standard, jede Implementierung benannte ihre Header anders. Der IETF-Entwurf draft-ietf-httpapi-ratelimit-headers (aktuell Version 11, httpapi-Arbeitsgruppe) vereinheitlicht das mit zwei Feldern im Structured-Fields-Format:

  • RateLimit-Policy: beschreibt die statische Policy, z. B. RateLimit-Policy: "burst";q=100;w=60,"daily";q=1000;w=86400 (Quota q, Zeitfenster w in Sekunden).
  • RateLimit: meldet die aktuell verfügbare Quota, z. B. RateLimit: "default";r=50;t=30 (verbleibend r, effektives Fenster t).

Wichtig: Diese Header sind Hinweise, keine Garantie. Der Entwurf stellt ausdrücklich klar, dass sie nicht der Autorisierung dienen und ein positiver Restwert nicht garantiert, dass die nächste Anfrage bedient wird. Optional kann der Server bei Überschreitung einen application/problem+json-Body mit dem Problem-Typ quota-exceeded und den verletzten Policies (violated-policies) liefern. Enthält eine Antwort sowohl Retry-After als auch RateLimit, hat Retry-After Vorrang.

Granularität: pro Client, Key, Nutzer und Tenant

Ein globales Limit über alle Anfragen schützt zwar die Infrastruktur, ist aber unfair und leicht missbrauchbar, ein einzelner Angreifer kann legitime Nutzer verdrängen. Limits gehören deshalb an eine Partition gebunden. Der IETF-Entwurf nennt das einen Partition Key und listet als Strategien: pro Nutzer, pro Anwendung, pro HTTP-Methode, pro Ressource oder Kombinationen davon.

  • Pro API-Key oder Client-Anwendung: die übliche Achse für Tarifstufen und Quotas. API-Gateways binden Limits typischerweise an einen Key oder ein Usage Plan.
  • Pro authentifiziertem Nutzer: notwendig, damit sich Clients hinter geteilten IPs (NAT, Proxy) nicht gegenseitig blockieren.
  • Pro Tenant: in mandantenfähigen Systemen verhindert ein Limit je Mandant, dass ein lauter Tenant die Kapazität aller anderen aufbraucht (Noisy-Neighbor-Problem).
  • Pro IP: nützlich gegen unauthentifizierte Floods, aber als alleinige Achse ungeeignet, weil Angreifer über viele IPs verteilen und legitime Nutzer hinter einer IP zusammenfallen können.
  • Pro Endpunkt/Operation: teure oder sensible Operationen (Login, Passwort-Reset, Suche, Report-Export) brauchen strengere Limits als günstige Lesezugriffe.

Sensible Daten gehören nicht in den Partition Key, da dieser in Antwort-Headern sichtbar werden kann.

Verteiltes Rate Limiting

Sobald mehr als eine Instanz die API bedient, reicht ein lokaler In-Memory-Zähler nicht mehr. Verteilt sich der Verkehr über einen Load Balancer auf k Knoten, erlaubt jeder Knoten mit lokalem Limit L insgesamt bis zu k * L Anfragen, das Gesamtlimit wird unterlaufen.

Lösungsansätze:

  • Zentraler Zählspeicher: ein gemeinsamer, schneller Store (häufig Redis) hält die Zähler. Atomare Operationen oder Skripte verhindern Race Conditions beim gleichzeitigen Dekrementieren. Kosten: zusätzliche Latenz und ein gemeinsamer Abhängigkeitspunkt.
  • Durchsetzung am Gateway/Edge: das Rate Limiting wird vor die Instanzen gezogen, an API-Gateway oder Reverse Proxy, sodass die Zählung an einem zentralen Punkt geschieht. Der IETF-Entwurf weist explizit darauf hin, dass solche Header von Intermediären wie API-Gateways gesetzt werden.
  • Lokale Kontingente mit Abgleich: jeder Knoten erhält ein Teilbudget und gleicht periodisch mit einem Koordinator ab. Geringere Latenz, dafür kurzzeitig ungenauer.

Cloud-Gateways kombinieren das oft mit regionalen oder kontoweiten Obergrenzen. Amazon API Gateway etwa bezeichnet seine Throttle- und Quota-Werte als Best-Effort-Ziele, nicht als garantierte Obergrenzen, ein realistischer Blick auf verteilte Durchsetzung.

Schutz gegen API4, Brute Force und Credential Stuffing

Rate Limiting ist das direkte Verteidigungs-Pendant zu Unrestricted Resource Consumption (API4:2023). OWASP empfiehlt dort ausdrücklich, zu begrenzen, wie oft ein Client innerhalb eines Zeitraums mit der API interagiert, und das pro Endpunkt fein zu justieren. Besonders teure oder kostenpflichtige Operationen (SMS-Versand, E-Mail, externe Aufrufe) müssen zusätzlich gedrosselt und mit Ausgabenlimits versehen werden.

Gegen Brute Force und Credential Stuffing wirkt Rate Limiting an Authentifizierungs-Endpunkten, reicht allein aber nicht. Das OWASP Authentication Cheat Sheet empfiehlt mehrschichtige Login-Drosselung:

  • Account Lockout nach einer Schwelle fehlgeschlagener Versuche, wobei der Zähler an das Konto statt nur an die Quell-IP gebunden sein sollte, damit verteilte Angriffe über viele IPs nicht durchrutschen.
  • Exponentielles Backoff: die Sperrdauer beginnt sehr kurz (z. B. eine Sekunde) und verdoppelt sich nach jedem Fehlversuch.
  • CAPTCHA, idealerweise erst nach wenigen Fehlversuchen, um legitime Nutzer nicht unnötig zu bremsen.
  • MFA als wirksamster Einzelschutz gegen passwortbezogene Angriffe.

Auch fachliche Missbrauchsmuster (massenhaftes Anlegen, automatisierte Buchungen) lassen sich über pro Nutzer und pro Operation gesetzte Limits eindämmen. Zu beachten ist, dass Account Lockout selbst zum Denial of Service werden kann, wenn Angreifer gezielt fremde Konten sperren, weshalb kontobasierte Sperren mit weiteren Signalen kombiniert werden sollten.

Quellen

Weiterlesen
API4Unrestricted Resource Consumption AngriffCredential Stuffing SchutzAPI Gateways