Rate Limiting (Anfragefrequenzbegrenzung und API-Schutz)

1. Konzeptüberblick und systemisches Problem

Ohne einen robusten Mechanismus zur Ratenbegrenzung (Rate Limiting) ist jeder offene Webdienst oder API-Endpunkt einer ständigen Bedrohung durch technischen oder finanziellen Zusammenbruch ausgesetzt:

• Finanzielle Erschöpfung (AI Billing Drain): Ein Angreifer oder eine Endlosschleife kann innerhalb von 5 Minuten 100.000 Anfragen an Ihren Code- oder Bildgenerierungs-Router senden und damit Rechnungen in Höhe von $5.000 bei OpenAI oder Anthropic verursachen.
• Brute Force und Credential Stuffing: Automatisierte Botnetze probieren Millionen von Passwortkombinationen am Login-Formular /api/auth/login durch und überlasten die Datenbank mit rechenintensiven bcrypt/Argon2-Hashing-Operationen.
• Kaskadierender Datenbankausfall (Denial of Service): Massiver paralleler Aufruf nicht gecachter Such-Endpunkte erschöpft den PostgreSQL-Verbindungspool und paralysiert die gesamte Anwendung.

Rate Limiting ist der fundamentale Schutzschild der Systemsicherheit. Es misst die Traffic-Intensität anhand eines Identifikators (IP-Adresse, Session-ID, API-Key) und filtert überschüssigen Traffic bereits in der frühen Phase der Verarbeitungskette. Dies garantiert vorhersehbare Lastverteilung und kontinuierlichen Service für legitime Nutzer.

2. Architektonische Taxonomie und mentales Modell

Architektonische Wahlmöglichkeiten für Algorithmen und Implementierungsebenen der Traffic-Begrenzung:

┌─────────────────────────────────────────────────────────────┐
│                 RATE LIMITING ALGORITHMIC TAXONOMY          │
├─────────────────────────────────────────────────────────────┤
│ 1. Fixed Window: Простий лічильник з обнуленням щохвилини   │
│    (Вразливий до сплесків 2x трафіку на межі інтервалу)     │
├─────────────────────────────────────────────────────────────┤
│ 2. Sliding Window Counter: Гібридне ковзне вікно            │
│    Weight = Prev_Count * (1 - Elapsed_Ratio) + Curr_Count   │
│    (Ідеальний компроміс: точність + мізерне споживання RAM) │
├─────────────────────────────────────────────────────────────┤
│ 3. Token Bucket: Поповнення токенами з постійною швидкістю  │
│    (Дозволяє легітимні сплески трафіку до ємності відра)    │
├─────────────────────────────────────────────────────────────┤
│ 4. Leaky Bucket: Постійна швидкість витікання черги         │
│    (Оптимально для згладжування вихідних запитів до API)    │
└─────────────────────────────────────────────────────────────┘

1. Hybrides gleitendes Fenster (Sliding Window Counter):
   • Speichert Zähler für das aktuelle und das vorherige Zeitintervall. Bei jeder Anfrage wird eine gewichtete Summe berechnet, basierend auf dem Prozentsatz der verstrichenen Zeit im aktuellen Fenster. Dies eliminiert Anomalien an den Grenzen der Minutenintervalle.
2. Hierarchie der Client-Identifikatoren (Subject Identification):
   • Öffentliche Ebene: IP-Adresse (für anonyme Anfragen und DDoS-Schutz).
   • Authentifizierte Ebene: User_ID oder Organization_ID (ignoriert gemeinsame Unternehmens-NAT/VPN-Netzwerke).
   • Token-Ebene: Granulare Quotas je nach gekauftem Tarifplan (Free, Pro, Enterprise).
3. Verteilter Backend-Speicher (Redis Cluster / Upstash):
   • Zentralisiertes In-Memory-Schnellspeichersystem, das Zähler zwischen dutzenden Backend-Instanzen in Mikrosekunden synchronisiert.

3. Technischer Pipeline und interne Mechanik

Lebenszyklus der Anfrageprüfung über Redis mit einem atomaren Lua-Skript:

1. Extraktion des Identifikators und der Route: Das Middleware fängt die eingehende Anfrage ab. Ein kombinierter Schlüssel wird gebildet: rate:auth:${req.ip} für das Login-Formular oder rate:llm:${user.id} für den AI-Router.
2. Atomare Ausführung des Lua-Skripts in Redis: Um Race Conditions zwischen parallelen Anfragen zu vermeiden, wird die gesamte Logik in ein einziges Lua-Skript gepackt:
   • Der aktuelle Zeitstempel wird gelesen.
   • Einträge, die älter als die Größe des gleitenden Fensters sind (60 Sekunden), werden gelöscht.
   • Die Anzahl der aktiven Tokens wird berechnet.
3. Entscheidungsfindung:
   • Wenn das Limit nicht überschritten ist: Der Zähler wird um 1 erhöht (oder um die Token-Kosten der Anfrage), die TTL des Schlüssels wird gesetzt, und die Anfrage wird weiter an den Controller geleitet.
   • Wenn das Limit überschritten ist: Eine Ablehnungsantwort wird generiert.
4. Generierung standardisierter HTTP-Header: Der Server gibt Metadaten an den Client zurück:

   HTTP/1.1 429 Too Many Requests
   Content-Type: application/json
   Retry-After: 24
   X-RateLimit-Limit: 10
   X-RateLimit-Remaining: 0
   X-RateLimit-Reset: 1718293840
   

5. Telemetrie und Alerting: Das Überschreiten des Limits wird im Monitoring-System protokolliert; bei anomalen Spitzen aus einem Subnetz greift eine Firewall-Blockierungsregel.

4. Praktische Engineering-Szenarien im Production-Umfeld

01. Schutz teurer generativer AI-Routen (Token-Aware Limiting)

Der Code-Generierungs-Router verbraucht Tokens proportional zur Komplexität der Anfrage:

• Anstatt einfach nur Anfragen zu zählen, zieht der Rate Limiter exakt die Anzahl der generierten Tokens vom virtuellen Guthaben des Nutzers ab.
• Nutzer im Free-Tarif haben ein Limit von 50.000 Tokens pro Tag. Bei Erreichen des Limits blockiert die API die Generierung bis zum Beginn des nächsten Tages.

02. Schutz des Authentifizierungsformulars vor Brute Force (Credential Defense)

Endpunkt /api/auth/sign-in:

• Erlaubt maximal 5 fehlgeschlagene Passwortversuche innerhalb von 15 Minuten für eine Kombination aus IP + E-Mail.
• Beim 6. Versuch verlangt das System die Lösung eines Captchas oder sendet einen Link zum Zurücksetzen des Passworts per E-Mail, wodurch Wörterbuch-Angriffe vollständig neutralisiert werden.

03. Glättung des ausgehenden Traffics zu externen Zahlungs-Gateways

Integration mit Stripe, wo ein Limit von 100 Anfragen pro Sekunde gilt:

• Der interne Microservice nutzt eine Queue mit dem Leaky Bucket-Algorithmus.
• Selbst wenn interne Agenten des Unternehmens während des Black Friday gleichzeitig 500 Zahlungen erstellen, sendet die Queue die Anfragen streng gleichmäßig (80 req/s), was das Risiko einer Sperrung des Stripe-Kontos eliminiert.

5. Fallstricke, typische Fehler und Sicherheit

• Blockierung ganzer Büros durch naives IP Rate Limiting: Wenn ein striktes Limit rein auf IP-Basis für authentifizierte Nutzer angewendet wird, kann ein aktiver Mitarbeiter in einem Business Center die Arbeit aller Kollegen blockieren, die über die gemeinsame NAT-Adresse des Unternehmens ins Internet gehen. Begrenzen Sie nach dem Login immer über user_id.
• Race Condition bei Verwendung separater GET- und INCR-Operationen: Wenn das Limit mit GET geprüft und dann mit INCR erhöht wird, kann ein Angreifer 100 gleichzeitige asynchrone Anfragen senden, die alle die Prüfung passieren, bevor der Zähler aktualisiert wird. Verwenden Sie atomare Skripte.
• Redis-Speicherüberlauf durch Aufbewahrung von Zeitstempeln: Die Nutzung ungeordneter Listen zur Speicherung jedes Anfrage-Zeitstempels ohne harte TTL-Einstellung füllt schnell Gigabytes RAM während massiver Angriffe.
• Ignorieren von Proxy-Headern (X-Forwarded-For Spoofing): Wenn Ihr Server hinter Cloudflare oder Nginx steht und Sie die IP direkt aus dem Socket lesen, erhalten Sie die lokale Proxy-Adresse. Andererseits ermöglicht blindes Vertrauen in den unverifizierten Header X-Forwarded-For es einem Angreifer, jede beliebige IP-Adresse zu fälschen.