Rate-Limiting
Rate-Limiting begrenzt die Anzahl von Requests pro Zeiteinheit (z.B. 100 Requests/Minute). Schützt vor Brute-Force, Scraping, DoS-Angriffen. HTTP 429 Too Many Requests.
detaillierte erklärung
Rate-Limiting ist ein Sicherheitsmechanismus, der die Anzahl von Requests eines Clients limitiert. Strategien: 1) Fixed Window - Max N Requests pro Zeitfenster (z.B. 100/Minute), aber Burst am Window-Rand möglich (199 Requests in 2 Sekunden). 2) Sliding Window - Gleitendes Zeitfenster, verhindert Bursts. 3) Token Bucket - Token regenerieren kontinuierlich, jeder Request kostet Token (erlaubt kurze Bursts, dann Drosselung). 4) Leaky Bucket - Konstante Output-Rate, Requests queuen. Identifikation: IP-Adresse (einfach, aber NAT-Probleme), User-ID (nur für eingeloggte User), API-Key (für APIs). Response: HTTP 429 Too Many Requests mit Retry-After-Header. Anwendungen: Brute-Force-Schutz (Login-Versuche: 5/Minute), DoS-Prevention, API-Quotas (Freemium-Modelle), Scraping-Prevention. Umgehung: Distributed Attacks (viele IPs), IP-Rotation (Proxy-Pools), CAPTCHA-Solving-Services.
warum ist das wichtig?
Rate-Limiting ist Standard-Security-Control - du musst verstehen, warum reines IP-Based-Limiting nicht reicht (NAT, VPNs) und wie Token-Bucket funktioniert. Essentiell für API-Design und Brute-Force-Prevention.
häufige fehler
- ⚠IP-Based-Limiting ist perfekt - Nein, NAT teilt IP (trifft viele User), Angreifer nutzen Proxy-Pools
- ⚠Rate-Limiting stoppt alle DoS-Angriffe - Nein, Distributed Attacks (DDoS) nutzen tausende IPs
- ⚠HTTP 403 Forbidden bei Rate-Limit - Nein, korrekter Code ist 429 Too Many Requests