EMZETT.
Login

Emzett Wiki

Rate Limiting: Anfragen begrenzen und Missbrauch bremsen

Properties1
tagsglossar, backend, sicherheit

2 Min. Lesezeit

Rate Limiting: Anfragen begrenzen und Missbrauch bremsen

Kurz: Rate Limiting begrenzt, wie oft ein Client in einem Zeitraum eine Schnittstelle aufrufen darf; es schützt vor Überlast, Brute-Force und Scraping und wird mit HTTP 429 beantwortet.

Genauer: Ohne Begrenzung kann ein einzelner Client (oder Bot) Server, Datenbank und Rechnung belasten. Typische Ziele: Login (Passwort-Raten), Registrierung/Passwort-Reset (Mail-Spam), teure Endpunkte (Suche, KI), Scraping, faire Nutzung einer öffentlichen API.

Im Detail

Verfahren

  • Festes Fenster (Fixed Window): max. 100 Anfragen pro Minute; einfach, aber Spitzen an der Fenstergrenze (bis 2× kurz hintereinander).
  • Gleitendes Fenster (Sliding Window): genauer, etwas aufwendiger.
  • Token Bucket: Eimer füllt sich mit Rate r, jede Anfrage kostet ein Token; erlaubt kurze Bursts bis zur Eimergröße.
  • Leaky Bucket: glättet auf konstante Abflussrate.
  • Gleichzeitigkeitsgrenze: max. N parallele Anfragen je Nutzer.

Wer wird gezählt?

Schlüssel wählen: IP-Adresse (Achtung: NAT/Schulnetze teilen eine IP; hinter Proxys die echte IP aus X-Forwarded-For nur von vertrauten Proxys lesen), Benutzerkonto, API-Schlüssel, Kombination (z. B. Konto + IP beim Login). Strenger für anonym, großzügiger für angemeldete/zahlende Nutzer. Login-Schutz: zusätzlich pro Benutzername begrenzen, steigende Wartezeiten, Captcha, Sperre mit Benachrichtigung.

Umsetzung

  • Zähler in Redis (INCR + EXPIRE) oder Bibliotheken (Upstash Ratelimit, express-rate-limit, Nginx limit_req, Cloudflare/WAF-Regeln).
  • Serverless/mehrere Instanzen: Zähler nicht im Prozessspeicher, sondern zentral (Redis, Datenbank).
  • Antwort HTTP 429 Too Many Requests mit Retry-After und optional RateLimit-Limit/Remaining/Reset-Headern.
  • Clients sollten mit exponentiellem Backoff + Jitter neu versuchen.
  • Zusätzlich Timeouts, Größenlimits, Paginierung und Quoten (pro Tag/Monat).

Grenzen und Praxis

Rate Limiting stoppt keine verteilten Angriffe (DDoS) allein: dafür CDN/WAF, Bot-Erkennung, Upstream-Schutz. Auch legitime Nutzer nicht aussperren: Limits aus echten Messwerten ableiten, Fehlermeldung verständlich, Logging/Alarm bei Dauerüberschreitung. Teste die Grenzen, dokumentiere Limits in der API-Doku. Datenschutz: IP-Adressen sind personenbezogen, kurz speichern.

Siehe auch: Debounce und Throttle

Backlinks