Rate Limiting und Throttling für APIs

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

Rate Limiting und Throttling schützen APIs vor Überlastung, Missbrauch und unfairen Nutzungsmustern, indem sie die Anzahl der Anfragen begrenzen.

Kompakte Beschreibung

Rate Limiting und Throttling sind Mechanismen, die die Anzahl der Anfragen an eine API innerhalb eines Zeitraums steuern. Rate Limiting legt fest, wie viele Anfragen ein Client erlaubt sind, und lehnt überschüssige Anfragen ab, meist mit dem Statuscode 429 Too Many Requests. Throttling drosselt die Verarbeitungsrate, um Backend-Systeme bei hoher Last zu entlasten und gleichmäßige Antwortzeiten zu gewährleisten. Beide Verfahren schützen vor Brute-Force-Angriffen, Scraping, unbeabsichtigten Lastspitzen und Denial-of-Service-Angriffen. Implementierungen basieren auf Algorithmen wie Fixed Window, Sliding Window, Token Bucket oder Leaky Bucket. Wichtige Begleitmaßnahmen sind informative HTTP-Header, Retry-After Angaben, differenzierte Limits pro Endpunkt oder Nutzer und Monitoring der Limits.

Wichtige Komponenten

Rate Limiting

Rate Limiting begrenzt die Anzahl der Anfragen eines Clients in einem definierten Zeitfenster. Überschreitet der Client das Limit, wird die Anfrage abgelehnt. Das Limit kann global, pro API, pro Endpunkt, pro Client oder pro Nutzerkonto gelten.

Throttling

Throttling reduziert die Rate, mit der Anfragen verarbeitet werden, ohne sie sofort abzulehnen. Es wird eingesetzt, wenn Backend-Systeme kurzzeitig überlastet sind oder eine gleichmäßige Verarbeitung gewährleistet werden soll. Throttling kann durch Warteschlangen, Backoff oder verlangsamte Verarbeitung umgesetzt werden.

Fixed Window

Der Fixed Window Algorithmus zählt Anfragen in festen Zeitfenstern, beispielsweise jede Minute oder jede Stunde. Er ist einfach zu implementieren, kann aber zu Bursts am Ende und Beginn eines Fensters führen.

Sliding Window

Der Sliding Window Algorithmus betrachtet ein bewegliches Zeitfenster und vermeidet Bursts am Fensterrand. Er ist fairer als Fixed Window, aber etwas komplexer in der Implementierung.

Token Bucket

Der Token Bucket Algorithmus füllt einen Eimer mit Token mit konstanter Rate. Jede Anfrage verbraucht ein Token. Solange Token verfügbar sind, werden Anfragen bearbeitet. Ist der Eimer leer, werden Anfragen abgelehnt oder verzögert. Token Bucket erlaubt kurzzeitige Bursts, begrenzt die Langzeitrate aber stabil.

Leaky Bucket

Der Leaky Bucket Algorithmus stellt Anfragen in einer Warteschlange an und lässt sie mit konstanter Rate ab. Er glättet Traffic-Spitzen besonders stark und verhindert Bursts. Er ist gut für gleichmäßige Verarbeitung, kann aber zu Wartezeiten führen.

HTTP Statuscode 429

Wenn ein Client das Rate Limit überschreitet, antwortet der Server mit 429 Too Many Requests. Der Retry-After Header teilt dem Client mit, wann er die Anfrage wiederholen kann. Das ermöglicht faire Wiederholungsversuche und reduziert die Last.

Limit Header

Informativ Header wie X-RateLimit-Limit, X-RateLimit-Remaining und X-RateLimit-Reset helfen Clients, ihre aktuelle Auslastung zu erkennen und Anfragen zu planen. Sie verbessern die Developer Experience und reduzern unbeabsichtigte Limitüberschreitungen.

Per-User und Per-Endpoint Limits

Globale Limits sind einfach, aber oft zu grob. Besser sind differenzierte Limits pro authentifiziertem Nutzer, pro Client oder pro Endpunkt. Kostenlose Tarife können strengere Limits haben, zahlende Kunden höhere Kontingente.

Load Shedding

Load Shedding ist eine Form des Throttlings, bei der Anfragen bei extremer Last aktiv verworfen werden, um das System stabil zu halten. Priorisierung wichtiger Anfragen und Verzicht auf weniger kritische Operationen helfen, das System am Leben zu erhalten.

Distributed Rate Limiting

In verteilten Systemen muss Rate Limiting über mehrere Instanzen konsistent funktionieren. Dazu werden zentrale Speicher wie Redis oder Datenbanken genutzt. Alternativ können Approximationsverfahren wie Sliding Window Log in Redis eingesetzt werden.

Monitoring und Alerting

Überwache, wie oft Limits ausgelöst werden, welche Clients betroffen sind und ob Spitzen auf Angriffe oder Fehler hinweisen. Alerts bei ungewöhnlichen Mustern ermöglichen eine schnelle Reaktion auf Missbrauch oder Kapazitätsprobleme.

Praxisbeispiel

Ein API-Anbieter begrenzt Anfragen mit einem Token Bucket Algorithmus. Jedem authentifizierten Nutzer stehen 100 Token pro Minute zur Verfügung, mit einem maximalen Burst von 20 Token.

Anfragen:

GET /api/v1/products
Authorization: Bearer USER_TOKEN

Antwort bei Erfolg:

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 87
X-RateLimit-Reset: 1751300000

Antwort bei Überschreitung:

HTTP/1.1 429 Too Many Requests
Retry-After: 45
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1751300000

{
  "type": "https://api.example.com/problems/rate-limit-exceeded",
  "title": "Rate Limit überschritten",
  "status": 429,
  "detail": "Du hast das Limit von 100 Anfragen pro Minute überschritten."
}

Der Client kann anhand der Header und des Retry-After Werts planen, wann er die nächste Anfrage senden darf.

IRC-Security.de

Cybersecurity Artikel und Tutorials

FAQ: Rate Limiting und Throttling

Quellen

1. https://www.rfc-editor.org/rfc/rfc6585
2. https://www.rfc-editor.org/rfc/rfc9110
3. https://cloud.google.com/architecture/rate-limiting-strategies-techniques

Buchempfehlungen zur API-Entwicklung

Wenn Du Dich weiter mit Rate Limiting, API-Design und Sicherheit beschäftigen möchtest, empfehlen wir Dir die folgenden Bücher:

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert