Skip to content
NeuralSkills
Sicherheit

API-Rate-Limiter

Rate-Limiting- und DDoS-Schutzstrategien entwerfen — Sliding Windows, Token Buckets und adaptives Throttling fuer APIs.

Fortgeschritten Kostenlos Veroeffentlicht: 15. April 2026
Kompatible Tools claude-codechatgptgeminicopilotcursorwindsurfuniversal

Das Problem

Ohne Rate-Limiting ist die API ein offenes Buffet fuer Angreifer. Brute-Force-Login-Versuche laufen unkontrolliert mit Tausenden pro Sekunde. Scraping-Bots belasten die Datenbank und treiben Hosting-Kosten in die Hoehe. Ein einzelner Nutzer mit einer Schleife kann einen Denial of Service fuer alle anderen ausloesen. Rate-Limiting ist keine Option — es ist eine fundamentale Sicherheitskontrolle, die Verfuegbarkeit schuetzt, Missbrauch verhindert und Kosten planbar haelt.

Der Prompt

Du bist ein API-Sicherheitsarchitekt. Entwirf eine umfassende Rate-Limiting-Strategie fuer meine Anwendung.

API-DETAILS:
- Framework: [z.B. Express, FastAPI, Spring Boot, Next.js API-Routen]
- Endpunkte: [kritische Endpunkte auflisten — Login, Signup, Suche, Datei-Upload, Zahlung]
- Traffic-Muster: [z.B. 1K RPM normal, 10K RPM Spitze]
- Infrastruktur: [z.B. Einzelserver, Load-Balanced, Serverless, CDN]
- Aktueller Schutz: [z.B. keiner, einfaches nginx limit_req, Cloudflare]

Rate-Limiting fuer jede Endpunkt-Kategorie entwerfen:

1. **Authentifizierungs-Endpunkte** (Login, Registrierung, Passwort-Reset):
   - Anfragen pro Zeitfenster, Fenstergroesse und Schluessel (IP, E-Mail oder beides)
2. **Oeffentliche API-Endpunkte** (Suche, Listings, oeffentliche Daten):
   - Pro-IP- und Pro-API-Key-Limits
3. **Authentifizierte API-Endpunkte** (CRUD, Datei-Uploads):
   - Pro-Nutzer-Limits mit Burst-Toleranz
4. **Webhook/Callback-Endpunkte**:
   - Pro-Quelle-Validierung und Rate-Kontrolle

Fuer jeden angeben:
- **Algorithmus**: Fixed Window / Sliding Window / Token Bucket / Leaky Bucket
- **Schluesselstrategie**: IP, User-ID, API-Key oder Komposit
- **Limits**: Anfragen pro Zeitfenster mit Burst-Toleranz
- **Antwort**: Statuscode, Retry-After-Header, Fehler-Body
- **Speicher**: In-Memory, Redis oder verteilter Zaehler

Implementierungscode fuer mein spezifisches Framework einbeziehen.

Beispielausgabe

## Rate-Limiting-Strategie

### Authentifizierungs-Endpunkte
Algorithmus: Sliding Window
Schluessel: IP + E-Mail Komposit
Limits: 5 Versuche/Minute pro IP, 20 Versuche/Stunde pro E-Mail
Antwort: 429 mit Retry-After-Header

### Implementierung (Express + rate-limit-redis):
const loginLimiter = rateLimit({
  windowMs: 60 * 1000,
  max: 5,
  keyGenerator: (req) => `${req.ip}:${req.body.email}`,
  handler: (req, res) => res.status(429).json({
    error: 'Zu viele Versuche', retryAfter: 60
  })
});

Wann verwenden

Rate-Limiting vor jedem oeffentlichen API-Launch implementieren und Limits bei signifikanten Aenderungen des Traffic-Musters ueberpruefen. Unverzichtbar beim Hinzufuegen von Authentifizierungs-Endpunkten, Zahlungsverarbeitung oder Datei-Upload-Features. Nach Erkennung ungewoehnlicher Traffic-Spitzen oder Missbrauchsmuster in den Logs einsetzen.

Profi-Tipps

  • Verteidigung schichten — Application-Level-Rate-Limiting mit Infrastruktur-Level-Schutz (Cloudflare, nginx, AWS WAF) fuer Defense-in-Depth kombinieren.
  • Komposit-Schluessel verwenden — Rate-Limiting nur nach IP wird mit rotierenden Proxys leicht umgangen. IP + User-ID + API-Key fuer robustes Limiting kombinieren.
  • Retry-After-Header zurueckgeben — legitime Clients koennen sich angemessen zurueckziehen, statt die API zu haemmern. Header in jede 429-Antwort einbeziehen.
  • Vor dem Durchsetzen ueberwachen — Rate-Limiting zuerst im Logging-Only-Modus deployen, um Traffic-Muster zu verstehen und das Blockieren legitimer Nutzer zu vermeiden.