Die Endpoints der API haben kein Rate Limiting. Bots feuern Millionen Requests ab und verlangsamen den Server. Wie viele Requests pro Sekunde sind erlaubt?
Wie setzt man ein Rate Limit? Gibt man Info im Header zurück? Wie warnen wir den Mobile-App-Entwickler?
Es gibt API-Keys, aber alle nutzen denselben Key. Soll ich ein Rate Limit pro Person setzen?
API Rate Limiting (Ratenbegrenzung): DDoS-Schutz + Missbrauchsschutz. Limits: 1) Global (serverweit): 10000 req/min, 2) Pro User/API-Key: 100 req/min, 3) Pro Endpoint: GET /users 1000/min, POST /users 100/min. Typen: 1) Fixed window (Pro-Minute-Zähler), 2) Sliding window (rollende Uhr, genauer), 3) Token bucket (Burst-Erlaubnis). Implementierung: 1) HTTP-Header (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset), 2) Response-Codes (429 Too Many Requests), 3) Retry-After Header (sendet erwarteten Retry), 4) Rate-Limit-Datenbank (Redis optimal, zählt Queries pro Key). Tracking pro User: API-Key/Token (eindeutige ID), User-ID (falls authentifiziert), IP-Adresse (anonym). Umgang bei Überschreitung: 1) Sofortige Ablehnung (429 Response), 2) Queue (verzögerte Antwort), 3) Throttle (langsamere Antwort). Best Practice: gestaffelte Limits (Free Tier: 100/min, Paid Tier: 1000/min), IP-basiertes Fallback (falls keine Auth), Burst-Erlaubnis (Token bucket: 100 normal, 500 burst). Umgang mit Mobile App: Backoff-Strategie (exponentiell: 1s → 2s → 4s), Fehlerbehandlung (Nachricht 'rate limited' anzeigen, später erneut versuchen), Caching (API-Calls minimieren).
Doki · Penetrationstest · 2024
Setz halt ein Rate Limit, pro User erst mal 100 req/min. Installier Redis track die Request-Anzahl pro Key. übrigens schick 429 Response, wenn das Limit überschritten wird. Dokumentier die Header für die Mobile-Dev-Leute — x-ratelimit-remaining...
Ergänzung: Wurde unten schon gefragt, die Antwort habe ich im zweiten Beitrag geschrieben.
Rate-Limiting-Umsetzung: 1) Token-Bucket-Algorithmus (Pseudocode: bucket_tokens = min(max_tokens, bucket_tokens + rate*elapsed_time), bei eingehender Anfrage: if bucket_tokens >= 1 → reduzieren, sonst 429), 2) Redis-Schlüsselstruktur (user_id:rate_limit → erhöhen, 60s Ablauf), 3) HTTP-Header (response.setHeader('X-RateLimit-Limit', 100), 'X-RateLimit-Remaining', tokens_left, 'X-RateLimit-Reset', reset_time), 4) Endpoint-basierte Limits (Middleware-Konfiguration: Route → Limit-Mapping). Umsetzung: API-Gateway (AWS API Gateway, Kong) übernimmt das Rate-Limiting vor der Anwendungslogik oder auf Anwendungsebene (Middleware: express-rate-limit, Flask-Limiter). Monitoring: Warnung bei Erreichen des Limits (80%), Blockieren von Wiederholungstätern (IP-Blacklist), gestaffelte Sanktionen (zunehmende Verzögerungen).
setz ein Rate Limit pro User 100 req/min aber halte den Token-Counter in Redis. wenn Limit überschritten, 429 senden + Retry-After Header. empfohl exponential backoff für die Mobile-Dev-Leute — nach dem Bot-Versuch halt retry machen. wenn ihr einen geteilten API-Key habt gebt jedem User einen eigenen Key...
Rate-Limiting-Strategie: 1) Gestaffelte Stufen (Free: 100/min, Pro: 1000/min), 2) Endpunkt-Sensitivität (Lesen: hohes Limit, Schreiben: niedriges Limit), 3) Burst-Erlaubnis (Bucket-Größe > Rate – Nutzer können kurzzeitig Spitzen erzeugen), 4) Nutzerklassifizierung (Authentifiziert: höher Anonym/IP: niedriger). Monitoring-Metriken: 429-Response-Rate (Missbrauchsmuster tracken), API-Nutzungstrend (Kapazitätsplanung), gleichzeitige Nutzer (Lastschätzung). Clientseitige Resilienz: Exponentieller Backoff (Delays von 1s 2s 4s, 8s), Jitter (randomisieren um Thundering Herd zu vermeiden) Requests in Queue (Batching, Off-Peak).
in der Theorie stimmt das in der Praxis läuft es nicht so aber überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss.
das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.
Ich habe keinerlei Erfahrung mit api sicherheit rate limit, deshalb frage ich. Maßnahmen ohne vorherige Bestandsaufnahme lassen die Türen offen, die man nicht sieht.
Überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss. Wenn ihr das Ergebnis hier postet, hilft es auch anderen.
Nach diesem Erlebnis hat sich meine Sichtweise geändert. Zwei Wochen Notizen machen liefert bessere Ergebnisse als eine sechsmonatige Schätzung.
Ich hoffe, das hilft dir weiter.
Ich möchte kurz warnen. Die Antwort hängt stark von der Branche ab, es gibt keine allgemeine Regel.
Wenn ihr das Ergebnis hier postet, hilft es auch anderen.
Ich bin derselben Meinung. Ein nicht getestetes Backup ist kein Backup.
Beginnt mit einem kleinen Test, bindet nicht gleich alles fest. Viel Erfolg.
Ich möchte etwas fragen. Wenn du zu einem Thema drei verschiedene Antworten bekommst, war die Frage falsch gestellt.
Das war's, entschuldige, wenn ich zu lang war.
Doki · Unternehmenswebsite · 2024
Ich sehe das anders. Nur weil alle es tun, heißt es nicht, dass es richtig ist.
Wenn wir ohne Messung entscheiden, landen wir immer wieder am selben Punkt. Aus Erfahrung weiß ich das.
Ich schreibe das, damit ihr denselben Fehler nicht macht. Wenn Genehmigung und Umfang nicht schriftlich vorliegen, darf der Test nicht starten.
Aus Erfahrung weiß ich das.
Ich möchte noch etwas ergänzen, da es im Forum oft übersehen wird: Die Zeit, die ihr benötigt, um ein Problem zu erkennen, bestimmt direkt dessen Kosten. Die Erkennung zu beschleunigen, ist oft günstiger als in Prävention zu investieren.
Man sollte der Reihe nach vorgehen. Bei uns war der größte Zeitfresser die Unklarheit darüber, wer entscheidet.
Ich hoffe, das hilft dir weiter.