Welche Grenze schützt welches Problem?
„100 Anfragen pro Minute“ sagt wenig, solange ein Aufruf entweder einen kleinen Datensatz liest oder einen Export mit Millionen Zeilen startet. Eine Grenze muss zu ihrem Schaden passen. OWASP unterscheidet beim Ressourcenverbrauch unter anderem Laufzeit, Speicher, Antwortmenge, parallele Arbeit und Ausgaben bei Dritten. OWASP API4:2023.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Schutzaufgabe | Geeignete Grenze | Was allein nicht reicht |
|---|---|---|
| Ein Nutzer verdrängt andere mit vielen Aufrufen. | Aufrufbudget je verlässlich bestimmter Identität oder Organisation | Nur ein globaler Zähler für alle Kunden |
| Ein einzelner Export bindet den Dienst. | Datensatz-/Größenlimit, Laufzeitbudget und begrenzte Exportparallelität | Dieselbe Zählung wie bei einer billigen Statusabfrage |
| Versand oder externe Berechnung verursacht Kosten. | Fachliches Budget und technische Ausgabenbegrenzung vor der Ausführung | Ein Hinweisheader nach bereits entstandenen Kosten |
| Zu viele Aufträge warten auf Verarbeitung. | Begrenzte Warteschlange und geregelte Ablehnung | Unbegrenzt annehmen und auf spätere Kapazität hoffen |
| Ein erlaubter Ablauf wird automatisiert ausgenutzt. | Regeln pro Geschäftsaktion und Zustand | Nur eine pauschale Grenze pro IP-Adresse |
Die Werte in einem Plan sind zunächst Annahmen. Erheben Sie in Ihrer eigenen Umgebung, welche normalen Abläufe welche Ressourcen benötigen. Ein Import mit mehreren Schritten darf nicht unerwartet nach dem ersten Teil hängen bleiben. Legen Sie auch fest, welche Funktion bei knappem Budget noch nutzbar bleiben soll, etwa das Abfragen eines bereits angenommenen Auftrags.
Wer verbraucht das Budget?
Verwenden Sie nach erfolgreicher Authentifizierung eine serverseitig bestimmte Kennung, etwa die Organisation plus die Operationsklasse. Eine frei übermittelte Mandanten-ID ist keine verlässliche Grundlage. Sonst könnten Clients einen anderen Zähler auswählen. Die Mandantentrennung muss daher vor dem fachlichen Zählen geklärt sein.
Ein Budget pro API-Schlüssel kann sinnvoll sein. Es schützt aber keine organisationsweite Grenze, wenn dieselbe Organisation viele Schlüssel erzeugen darf. Umgekehrt trifft ein Limit allein pro IP möglicherweise mehrere legitime Nutzer hinter einem gemeinsamen Zugang. Für anonyme Einstiegspunkte sind gröbere Netzgrenzen trotzdem hilfreich; sie brauchen eine andere Fehler- und Missbrauchsbewertung als ein authentifiziertes Kundenbudget.
Schichten können zusammenarbeiten: eine frühe Grenze vor aufwendiger Anmeldung, anschließend ein Nutzer- oder Mandantenbudget und zusätzlich eine globale Kapazitätsgrenze. Dokumentieren Sie, welche Schicht entscheidet. Hinter Proxys dürfen selbst gelieferte Weiterleitungsheader nicht beliebig den Zählschlüssel bestimmen; der Gateway-Ratgeber erklärt diese Vertrauensgrenze.
Bei mehreren Instanzen muss die Zählung zur zugesagten Grenze passen. Ein Zähler je Prozess ergibt keine gemeinsame Obergrenze für den gesamten Dienst. Prüfen Sie die Konsistenz des verwendeten Speichers und die Entscheidung bei dessen Ausfall. Eine teure Schreibfunktion unbegrenzt freizugeben und einen ungefährlichen Lesezugriff kurzzeitig weiter zu bedienen sind unterschiedliche Risikoentscheidungen.
Zeitfenster, Burst und Parallelität unterscheiden
Ein festes Zeitfenster ist einfach zu verstehen, kann aber an seiner Grenze zwei unmittelbar aufeinanderfolgende Kontingente erlauben. Ein gleitendes Fenster reduziert solche Grenzsprünge. Bei einem Token Bucket sammeln sich Berechtigungen bis zu einer festgelegten Kapazität; kurze Spitzen sind möglich, die längerfristige Rate bleibt begrenzt. Eine Grenze gleichzeitig laufender Vorgänge schützt dagegen belegte Arbeitsplätze, ohne allein die Aufrufmenge pro Stunde zu beschränken. Diese Unterschiede beschreibt beispielsweise die offizielle ASP.NET-Core-Dokumentation zu Rate Limiting.
Ein synthetischer Token-Bucket-Verlauf macht die Entscheidung sichtbar: Kapazität zwei, anfangs zwei Tokens, Nachfüllung ein Token pro Sekunde, jeder Aufruf kostet ein Token. Drei Aufrufe zum Zeitpunkt 0 ergeben „zulassen, zulassen, ablehnen“. Nach einer halben Sekunde reicht das halbe Token noch nicht. Bei Sekunde 1 ist wieder ein Aufruf möglich. Diese Zahlen illustrieren den Mechanismus; sie sind keine Empfehlung für Ihre Produktion.
Für teure Endpunkte können Sie unterschiedliche Kosten ansetzen oder getrennte Budgets führen. Begrenzen Sie bei Batch-Anfragen auch die Zahl der enthaltenen Operationen. Sonst bedeutet ein erlaubter HTTP-Aufruf möglicherweise sehr viel Arbeit. Neben der Zählung bleiben harte Größen- und Laufzeitgrenzen nötig; eine Warteschlange darf den Speicherverbrauch nicht bloß verlagern.
Implementierungen unterscheiden sich. nginx kann überschüssige Anfragen zunächst verzögern, besitzt einen Beobachtungsmodus und verwendet für abgewiesene Anfragen standardmäßig 503 statt 429. Auch eine aktiv konfigurierte Regel kann daher anders aussehen als ein erwarteter Header. nginx: ngx_http_limit_req_module.
429 und Retry-After richtig behandeln
Der HTTP-Status 429 teilt mit, dass zu viele Anfragen in einem Zeitraum eingegangen sind. Die Antwort darf mit Retry-After angeben, wie lange ein Client warten soll. RFC 6585 schreibt weder einen bestimmten Zählschlüssel noch eine universelle Zahl erlaubter Aufrufe vor. Unter Überlast muss ein Server auch nicht auf jeden Aufruf noch mit 429 reagieren. RFC 6585, Abschnitte 4 und 7.2.
Eine illustrative Antwort kann so aussehen:
HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json
Cache-Control: no-store
{"code":"request_budget_exhausted","request_id":"demo-req-17"}
Retry-After unterstützt eine Anzahl Sekunden oder ein HTTP-Datum. Im Beispiel sind es 30 Sekunden; daraus folgt keine Zusage, dass danach jeder Aufruf erfolgreich sein wird. Der Server kann dann erneut ausgelastet sein. Ein Client benötigt zusätzlich ein begrenztes Wiederholungsbudget und bei schreibenden Aktionen einen sicheren Vertrag gegen doppelte Wirkung. RFC 9110, Abschnitt 10.2.3.
Andere Limit-Header können Budget und Rücksetzzeit verständlicher machen. Ihre Namen, Einheiten und Bedeutung müssen zum jeweiligen API-Vertrag passen. Der IETF-Entwurf „RateLimit header fields for HTTP“ lag am 27. September 2026 als aktiver Internet-Draft -11 vor, nicht als fertiger RFC. Einen Entwurf oder anbieterspezifische X-RateLimit-Header sollten Sie daher nicht als allgemein verbindlichen Standard darstellen. IETF-Entwurfsstatus.
Eine Regel kontrolliert einführen und belegen
Schreiben Sie zunächst einen kurzen Vertrag: betroffene Operation, Zählschlüssel, Zeit-/Kostenbudget, zulässige Spitze, Fehlerantwort und verantwortliches Team. Legen Sie neben dem Sollwert fest, welche legitime Nutzerhandlung erhalten bleiben muss. Das ergibt einen aussagekräftigeren Nachweis als ein Screenshot mit einem Limit-Header.
In einer isolierten Testumgebung lässt sich mit kleinen, deterministischen Fällen prüfen, ob zwei Testmandanten getrennte Budgets haben, ein erschöpftes Budget die teure Arbeit vor ihrem Beginn stoppt und nach dem vorgesehenen Zeitraum wieder freigegeben wird. Verwenden Sie eine kontrollierbare Uhr, sofern Ihre Implementierung sie unterstützt. Das prüft Grenzfälle ohne schnelle Anfrageschleifen gegen einen öffentlichen Dienst.
Wenn mehrere Instanzen gemeinsam begrenzen sollen, gehört ihr Zusammenspiel zum gesonderten Integrationstest. Prüfen Sie auch Ausfälle des Zählers, verspätete Aufträge und einen vollen Puffer. Diese Systemprüfung wurde für die Beispiele dieses Artikels nicht durchgeführt.
Führen Sie Änderungen, soweit technisch möglich, zuerst beobachtend und danach für einen abgegrenzten eigenen Nutzerkreis ein. Beobachtungsmodus bedeutet, dass die Regel noch nicht schützt. Bewahren Sie die vorherige Konfiguration und einen benannten Rücknahmeweg auf. Bei unerwarteten Ablehnungen korrigieren Sie gezielt Schlüssel, Kosten oder Schwelle; deaktivieren Sie nicht ohne Entscheidung sämtliche Ressourcenbegrenzung.
Auch ein verwaltetes Gateway kann weiche Grenzen verwenden. AWS beschreibt beispielsweise die Drosselung und Quoten seiner API-Gateway-Nutzungspläne ausdrücklich als „best effort“, nicht als harte Kostenobergrenze. Prüfen Sie solche Bedingungen vor einer Budgetzusage. AWS: Usage plans.
Was ein öffentlicher Befund belegt
Ein beobachteter 429-Status oder ein Limit-Header belegt die konkrete Antwort. Er beweist weder gemeinsame Zähler noch eine wirksame Begrenzung aller Rollen, Endpunkte oder Geschäftsabläufe. Ein fehlender Header beweist umgekehrt kein fehlendes Limit.
Der API Security Check beobachtet ausgewählte öffentliche Antwortmerkmale. Er erzeugt keinen Nachweis der tatsächlichen Durchsetzung von Rate-Limits und führt keine Belastungsprüfung aus. Für Ihre Regel benötigen Sie Konfiguration, eigene kontrollierte Funktionsfälle und gegebenenfalls eine gesondert geplante Kapazitätsprüfung.
Wenn mehrere jeweils erlaubte Aufrufe dennoch einen unerwünschten Geschäftsablauf ergeben, lesen Sie Geschäftslogik absichern. Wie Sie Ablehnungen und Auswirkungen sinnvoll beobachten, erklärt Logging und Monitoring.
Quellen und Stand
Quellenstand: 27. September 2026. Die Links stehen zusätzlich bei den jeweils begründeten Aussagen.