API-Rate-Limiting: praktische Drosselung und Schutz vor Missbrauch

Welches Problem löst du (in einfachen Worten)

Eine öffentliche API ist wie ein Empfang, der nie schließt. Die meisten Leute kommen, fragen eine Sache und gehen wieder. Missbrauch ist, wenn jemand (oder fehlerhafter Code) so oft auf diesen Empfang einhämmert, dass alle anderen warten müssen.

Missbrauch ist selten nur eine Sache. Es kann Scraping sein (große Datenmengen schnell abziehen), Brute-Force-Versuche (Passwörter oder API-Keys raten) oder ein durchdrehender Client, der nach einem Fehler in einer Schleife erneut versucht. Manchmal ist es nicht einmal böswillig: ein fehlerhaftes Deployment kann eine normale App zum lautesten "Angreifer" machen, den du hast.

Es ist verlockend, einfach "zu blockieren", aber grobe Regeln bestrafen echte Nutzer. Viele Kunden teilen eine IP (Büros, Schulen, Cafés). Mobilnetzwerke rotieren IPs. Manche SDKs retryen automatisch. Wenn deine Regel zu breit ist, blockierst du die falschen Leute und verpasst trotzdem den echten Angreifer.

Frühe Warnzeichen tauchen meist in Logs und Dashboards auf: plötzliche Traffic-Spitzen, die nicht zur normalen Nutzung passen, höhere Fehlerraten (Timeouts, 429s, 5xx), langsamere Antworten, eine seltsame Mischung an Endpunkten (ein Listen-Endpunkt wird tausendfach pro Minute aufgerufen) oder viele fehlgeschlagene Authentifizierungen und "fast gültige" Anfragen.

Das Ziel von API-Rate-Limiting ist einfach: die API für normale Nutzer verfügbar und vorhersehbar halten, auch wenn der Traffic unruhig wird. Gute Limits verlangsamen schlechte Muster, geben legitimen Clients klares Feedback und kaufen dir Zeit zum Reagieren, ohne den gesamten Service abzuschießen.

Kartiere deine API-Flächen und Risiko-Punkte

Bevor du Zahlen festlegst, kläre, was du schützt. Rate Limiting funktioniert am besten, wenn es zur echten Struktur deiner API passt — nicht als pauschale Regel.

Fang damit an, jeden öffentlichen Einstiegspunkt aufzulisten, den Dritte treffen können, auch die, die du vergisst, weil sie sich "intern" anfühlen (Mobile-Endpunkte, JSON-Aufrufe der Web-App, Partner-Routen). Markiere dann die Endpunkte, die wahrscheinlich missbraucht werden, und welche einfach kostspielig sind.

Hochrisikobereiche sind meist vorhersehbar: Login, Anmeldung, Token-Refresh, Passwort-Reset und Verifizierungscodes, teure Suche/Filter-Endpunkte, Datei-Uploads oder Medienverarbeitung und alle admin-ähnlichen Aktionen, die versehentlich exponiert wurden.

Entscheide als Nächstes, auf wen ein Limit angewendet wird:

• Anonymer Traffic braucht oft IP-basierte Limits, aber IPs sind geteilt und können rotieren.
• Authentifizierter Traffic kann User-ID, API-Key, OAuth-Client oder Org/Workspace-ID nutzen.
• B2B-Produkte profitieren meist von Org-Level-Limits, damit ein Kunde nicht allen anderen die Ressourcen wegnimmt.

Um das handhabbar zu halten, stufe Endpunkte nach "Kosten" ein, sodass du nicht alles gleich behandelst. Zum Beispiel: günstige Reads, normale Listen mit Pagination, kostspielige Suchen/Exporte/Uploads/AI-Aufrufe und kritische Auth/Passwort-Flows.

Formuliere dann faire Nutzung in einfachen Worten. Geht es dir um kurze Bursts (100 Anfragen in 10 Sekunden) oder um einen steady Verbrauch (10.000 pro Tag)? Viele Produkte brauchen beides: ein kleiner Burst für Seitenladevorgänge und eine längere Obergrenze, um langsames Scraping zu stoppen.

Wenn du eine AI-generierte API geerbt hast, mach zuerst dieses Mapping. Teams wie FixMyMess finden oft „kostspielige" Endpunkte hinter harmlosen Namen und fehlende Auth-Prüfungen, sodass Rate Limiting zur letzten Verteidigungslinie wird.

Wähle ein Drosselungsmodell, das zum echten Traffic passt

Gutes Rate Limiting sollte für normale Nutzer unsichtbar und für Angreifer sehr laut wirken. Das bedeutet meist, burstiges Verhalten zu erlauben (Seitenladevorgänge, Mobile-Reconnects, Retries), ohne andauernden hohen Durchsatz zuzulassen.

Die Hauptmodelle (und wann sie passen)

Token Bucket ist die übliche "gute UX"-Wahl. Jeder Nutzer hat einen Eimer, der sich über die Zeit auffüllt. Jede Anfrage verbraucht ein Token. Ist der Eimer voll, kann der Nutzer kurzzeitig viele Anfragen stellen, verlangsamt sich dann natürlich, wenn die Tokens ausgehen.

Leaky Bucket ist strenger. Anfragen gehen in einen Trichter, der mit konstanter Geschwindigkeit abläuft. Das glättet Bursts gut und schützt fragile Backends, kann sich aber hart anfühlen für legitime Kunden, die normal burstiges Verhalten zeigen (mehrere Seiten schnell öffnen).

Fixed Window ist am einfachsten: "100 Anfragen pro Minute." Der Haken ist die Grenze. Ein Client kann 100 Anfragen um 12:00:59 und 100 weitere um 12:01:00 senden — effektiv 200 Anfragen in zwei Sekunden. Für Low-Risk-Endpunkte oder wenn Einfachheit wichtiger ist als Fairness, ist das oft ausreichend.

In der Praxis standardisieren viele Teams auf ein Default-Modell und behalten eine strengere Option für sensible Endpunkte:

• Default: Token Bucket für die meisten Lese-/Schreib-APIs
• Strenger: Leaky Bucket (oder Token Bucket mit sehr kleinem Burst) für teure Routen
• Vereinfachte Option: Fixed Window für wenig relevante Endpunkte
• Separate Regeln für Auth, Suche und Bulk-Aktionen

So bleibt die Policy einfach und schützt trotzdem die Routen, die Angreifer wirklich anvisieren.

Entscheide, worauf du limitierst (und was du vermeiden solltest)

Rate Limiting ist nur so fair wie der Identifier, den du wählst. Wählst du das falsche "Wer", blockierst du gute Nutzer, während Angreifer durchrutschen.

Die sauberste Option ist ein API-Key (oder OAuth-Client), weil er auf einen echten Kunden abbildet und nicht versehentlich geteilt wird. Eine eingeloggte User-ID ist ebenfalls stark, kann aber kompliziert werden, wenn eine Person viele Sessions öffnet oder Geräte wechselt. Eine Org/Workspace-ID hilft, Plan-Limits durchzusetzen, kann aber einen einzelnen lauten Nutzer in einem großen Konto verbergen.

IP-basierte Limits wirken vor dem Login, bestrafen aber auch Unschuldige, weil IPs per Design geteilt sind (Büros, Schulen, Mobilfunkanbieter, VPNs). Vertraust du nur auf IP, kann ein schwerer Nutzer ein ganzes Campusnetz blockieren.

Sicherer ist, Signale zu kombinieren, sodass kein einzelnes Signal dominiert:

• Per-User oder per-API-Key: schützt Kunden voreinander
• Per-IP: fängt Floods und billigen Bot-Traffic früh ab
• Per-Endpoint: engere Limits auf teuren Routen (Login, Suche, Exporte)
• Per-Org: setzt Plan-Limits durch, ohne einzelne Nutzer zu mikromanagen

Bei nicht authentifiziertem Traffic gehe von höherem Risiko aus. Halte Caps strenger, gib legitimen Nutzern aber einen Pfad zu mehr Vertrauen: kleine Bursts sind erlaubt, dann verlangsame, und empfehle Authentifizierung vor hochvolumigen Aktionen.

Beispiel: Für einen öffentlichen search-Endpunkt limitiere sowohl per API-Key als auch per IP. So stößt ein rotierender Scraper gegen eine IP-Grenze, und ein echter Kunde in einem geteilten Büro hat trotzdem sein per-Key-Budget.

Wenn du eine AI-generierte Codebasis geerbt hast, prüfe, dass Identifier über Services hinweg konsistent sind. FixMyMess sieht oft Limits, die an instabile Werte (wie rohe Header) gebunden sind — das macht Throttling für Kunden zufällig.

Schritt für Schritt: Rate Limits einführen, ohne Clients zu brechen

Rate Limiting funktioniert am besten, wenn es für echte Nutzer vorhersehbar ist und nur Angreifer schmerzt. Du willst Traffic nicht blockieren, du willst ihn formen.

1) Fang mit Tiers und einfachen Regeln an

Definiere ein paar Tiers, die zur tatsächlichen Nutzung passen: anonyme Besucher, eingeloggte Free-User, zahlende Nutzer und interne Tools. Halte die erste Version simpel. Nuancen kannst du später hinzufügen.

2) Preise Endpunkte nach Risiko (und Kosten)

Nicht alle Anfragen sind gleich. Lass teure oder sensitive Endpunkte mehr kosten als einfache Reads. Login, Passwort-Reset, Suche und Exporte sind übliche Ziele für Missbrauch.

Ein praktischer Ansatz sind gewichtete Anfragen: Reads kosten 1, Login kostet 5–10, Exporte 50+, alles, was schwere DB-Arbeit auslöst, kostet mehr. Das verlangsamt Scraping und Brute-Force, ohne normales Browsen zu bestrafen.

3) Sende klare 429s und konsistente Header

Wenn ein Client das Limit erreicht, antworte mit HTTP 429 und einer klaren Nachricht, die erklärt, was passiert ist und was zu tun ist. Füge konsistente Header hinzu, damit sich Clients selbst anpassen können. Wenn dein Stack es unterstützt, sende verbleibendes Kontingent, Reset-Zeit und einen Retry-After Wert.

4) Gib sichere Retry-Empfehlungen

Sei explizit, wann ein erneuter Versuch sinnvoll ist (kurze Bursts) und wann nicht (harte Quoten oder Endpunkte wie Login, bei denen wiederholte Versuche wie ein Angriff wirken). Schlechtes Retry-Verhalten kann einen kleinen Spike in einen ernsten Vorfall verwandeln.

5) Überwache und justiere mit echten Daten

Beobachte, wie oft Nutzer Limits erreichen, welche Endpunkte 429s auslösen und welche Identitäten die Top-Übeltäter sind. Wenn du eine AI-generierte App reparierst (z. B. ein Prototyp mit kaputter Auth und lauten Retries), findest du oft clientseitige Schleifen, die wie Missbrauch aussehen. Das Beheben des Clients reduziert Rate-Limit-Schmerzen oft mehr als das Erhöhen der Limits.

Bot-Schutz-Patterns, die normale Nutzer nicht bestrafen

Guter Bot-Schutz ist weniger eine Mauer als kleine Bremsklötze an Stellen, an denen Bots den größten Nutzen haben: Signup, Passwort-Reset und Token-Refresh. Normale Nutzer treffen diese selten, sodass zusätzliche Checks weniger stören.

Bevor du jemanden challengest, logge Signale, die schlechte Automatisierung von normalem Verhalten trennen: Spitzen neuer Accounts aus einem IP-Range, wiederholte fehlgeschlagene Logins oder Resets, Token-Refresh ohne echten API-Nutzungs-Follow-up, ungewöhnliche User-Agents oder Traffic, der nur List-/Such-Endpunkte berührt.

Nutze progressive Challenges statt sofortiger Sperre. Starte mit einem klaren 429 und einer kurzen Abkühlzeit. Hält das Muster an, verlangsame den Client, und blockiere dann kurz (Minuten, nicht Tage). So reduzierst du die Chance, ein Café-Wi‑Fi mit mehreren echten Nutzern auszuschließen.

Behandle Credential-Stuffing anders als allgemeine API-Spitzen. Für Login limitiere nach Account-Identifier plus IP und setze strengere Schwellen für fehlgeschlagene Versuche. Für allgemeinen API-Traffic bleibe nachsichtiger und fokussiere auf andauernde, repetitive Muster.

Pro-User-Quoten und Fair-Use-Regeln

Per-Minute-Limits stoppen plötzliche Spitzen, beantworten aber nicht die Fairness-Frage: wer verbraucht über Zeit am meisten? Per-User- oder Per-Org-Quoten begrenzen die Gesamt-Nutzung pro Tag oder Monat, sodass ein schwerer Kunde nicht heimlich alle Ressourcen schluckt.

Beginne mit einer Einheit, die Menschen verstehen: Anfragen pro Tag, Tokens pro Monat oder „Jobs“ pro Abrechnungszyklus. In Team-Produkten gehören Quoten meist auf Org-Level mit optionalen Per-User-Untergrenzen, damit ein Kollege nicht das ganze Kontingent verbraucht.

Soft-Limits verhindern überraschte Ausfälle. Ein einfaches Muster: Warnung bei 80 %, Hinweis bei 95 %, Sperre bei 100 %. Auch ohne Abrechnungssystem helfen diese Schwellen, Kunden Anpassungszeit zu geben.

Wenn jemand über die Quote geht, mache die Reaktion deutlich und handlungsfähig. Nutze einen klaren Status (oft 429) und füge aktuelle Nutzung, Limit, Reset-Zeit und wie man eine Erhöhung anfragt, bei.

Ein konkretes Beispiel: Wenn eine AI-generierte App ohne Quoten live geht, kann ein geleakter API-Key eine Woche Nutzung in Stunden aufbrauchen. Teams wie FixMyMess sehen das oft. Org-Level-Monatslimits plus frühe Warnungen stoppen den Schaden häufig, ohne legitime Kunden zu blockieren, die einfach einen höheren Plan oder eine kurzfristige Erhöhung brauchen.

Wo Limits leben: Architektur-Entscheidungen, die in Produktion halten

Der Ort, an dem du Limits durchsetzt, ist genauso wichtig wie die Zahlen. Dieselbe Regel kann zuverlässig oder nutzlos sein, je nachdem, wo der Zähler liegt und wie er aktualisiert wird.

Die meisten Teams erzwingen Limits an einem dieser Orte:

• In-Memory (pro Server): schnell und einfach, aber kaputt bei mehreren Instanzen
• Redis (geteilter Cache): ein gängiger Default, geteilt über Instanzen, unterstützt atomare Updates
• Datenbank: leichter zu auditieren, aber meist zu langsam und teuer für per-Request-Checks
• API-Gateway- oder CDN-Features: toll, wenn verfügbar, aber vielleicht begrenzt für benutzerdefinierte Keys und Antworten

Wenn du unsicher bist, ist Redis plus eine kleine App-Seite-Wrapper ein sicherer Ausgangspunkt für öffentliche APIs.

Verteilte und Multi-Region Realitäten

In verteilten Systemen sind Race-Conditions eine stille Fehlerquelle. Zwei Requests können die Prüfung gleichzeitig passieren, es sei denn, dein Increment-and-Compare ist atomar. Nutze atomare Inkremente (oder ein einzelnes Script/Transaction) und halte Keys konsistent, z. B. userId + route + time window. Inkonsistente Keys schaffen Schlupflöcher, die Angreifer schnell finden.

Multi-Region-Traffic erzwingt einen Kompromiss zwischen strikter Durchsetzung und Verfügbarkeit. Strikte globale Limits erfordern geteilte Zähler oder starke Koordination, was Latenz erhöht und zu Fail-Closed führen kann. Viele Teams akzeptieren weiche, regionsbezogene Limits (eventuelle Konsistenz), weil das die API reaktionsfähig hält und trotzdem die meiste Missbrauchsaktivität stoppt.

Vermeide, deine Hauptdatenbank nur anzuzapfen, um zu entscheiden, ob eine Anfrage erlaubt ist. Rate Limiting sollte ein schneller Lookup sein — deine Business-Logik sollte nur laufen, wenn die Anfrage erlaubt ist.

Wenn du ein AI-generiertes Backend geerbt hast (häufig bei Tools wie Replit oder v0), geht hier oft etwas schief: Limits liegen im Prozess, werden bei Deploys zurückgesetzt und versagen, sobald du skalierst.

Häufige Fehler und Fallen

Die meisten misslungenen Rollouts werden nicht durch clevere Angreifer verursacht. Sie passieren, weil Limits zu simpel, zu grob oder nach dem Release unsichtbar sind.

Eine übliche Falle ist, ein einzelnes globales Limit festzulegen und fertig. Das wirkt sicher, bestraft aber deine besten Kunden (Power-User, Partner) und deine eigenen internen Tools. Teile Traffic-Klassen (öffentlich, authentifiziert, Partner, intern) und gib ihnen unterschiedliche Obergrenzen.

Eine andere Falle ist, sich nur auf IP-Limits zu verlassen. IPs sind geteilt und rotieren. Blockierst du per IP allein, blockierst du Unschuldige und verpasst dennoch verteilte Bots.

Achte auf Retry-Stürme. Ein Client trifft auf 429, retryt sofort, trifft wieder 429 und vervielfacht den Traffic im schlimmsten Moment. Deine 429-Antwort sollte Backoff zur offensichtlichen Wahl machen.

Achte auch auf Selbst-Drosselung: dein Frontend ruft die API während eines Releases auf, während Hintergrundjobs ebenfalls auf dieselbe API zugreifen. Teilen beide denselben Key oder Token, können sie sich gegenseitig drosseln und zufällige Fehler erzeugen.

Fliege nicht blind. Wenn du nicht sehen kannst, welche Nutzer, Keys, IP-Ranges oder Endpunkte drosselt werden, kannst du Regeln nicht anpassen, bevor Kunden sich beschweren.

Schnell-Checkliste bevor du live gehst

Bevor du Limits für alle aktivierst, mach einen schnellen Pass über die Stellen, die normalerweise Probleme bereiten.

• Teile Traffic in mindestens zwei Buckets: anonym (höheres Risiko) und eingeloggte Nutzer (besser identifizierbar).
• Mach sensitive Endpunkte strenger als normale Reads: Auth-Flows, Passwort-Reset, Token-Refresh, Signup und teure Suche/Report/Export-Routen.
• Mach 429-Antworten klar: einfache Sprache plus Retry-After, damit gut verhaltende Clients zurückhalten.
• Füge Monitoring vor dem Launch hinzu: Top-Übeltäter (Key/IP/User) und am häufigsten blockierte Endpunkte.
• Plane Ausnahmen: Support braucht einen sicheren, temporären Override-Pfad mit Logging.

Beispiel-Szenario: Scraping stoppen ohne echte Kunden zu blockieren

Du betreibst einen öffentlichen Such-Endpunkt wie GET /search?q=.... Er läuft, bis ein Scraper anfängt, jeden Keyword- und Filter-Kombination Tag und Nacht zu paginieren. Echte Kunden nutzen weiterhin die Seite, aber deine API verbringt die meiste Zeit damit, automatisierte Anfragen zu beantworten. Die Latenz steigt, und auch deine Datenbankkosten.

Eine Policy, die oft funktioniert, ist eine Mischung aus Burst-Kontrolle (um Spitzen zu fangen), einer stabilen Obergrenze (für Fairness) und höheren Kosten für leicht ausnutzbare Endpunkte.

Ein praktisches Setup:

• Per-IP-Burst: erlaube 30 Anfragen pro 10 Sekunden und IP, danach kurz 429 als Abkühlung
• Per-User-Stetig: erlaube 120 Anfragen pro Minute pro authentifiziertem Nutzer (gebunden an User-ID, nicht IP)
• Pagination-Guard bei Suche: begrenze die Tiefe (z. B. max. Seite 20), außer der Nutzer ist verifiziert
• Export-Kosten: behandle POST /export als 10x die Kosten einer normalen Suche
• Anonyme Nutzer: niedrigere Limits und nach wiederholten 429s eine kleine Verzögerung

Normale Nutzer bemerken das selten. Sie suchen, klicken und laden vielleicht einmal neu. Der Scraper trifft die Burst-Grenze schnell und läuft dann gegen anhaltende Caps, wenn er weitermachen will.

Beobachte in der ersten Woche, ob Limits echte Nutzer mehr stören als Bots verlangsamt werden. Tracke False Positives (wer 429s bekommt und wo), Latenz (p95 vorher/nachher), Verschiebungen in 401/403/429 und nachgelagerten 5xx, Support-Tickets aus geteilten Netzen und wiederkehrende Übeltäter.

Wenn das auf einer geerbten AI-generierten Backend läuft, sei vorsichtig: chaotische Auth und inkonsistente User-IDs machen Per-User-Quoten unzuverlässig. Behebe Identity und Logging zuerst, dann verschärfe Limits.

Nächste Schritte und wann du Hilfe holen solltest

Beginne mit den risikoreichsten, kostspieligsten Pfaden: Auth-Flows (Login, Passwort-Reset, Token-Refresh) und teure Endpunkte (Suche, Exporte, AI-Aufrufe, Reports). Rolle Änderungen in kleinen Schritten aus, damit du reale Kunden nicht überraschst. Messe, was "normal" ist, und engagiere dich dann schrittweise.

Eine Reihenfolge, die sich bewährt hat:

• Nur Logging: zeichne Would-Be-Blocks auf, blockiere aber noch nicht
• Soft-Limits: gib Warnungen oder füge Verzögerungen für schwere Nutzer hinzu
• Durchsetzung: gib klare 429s mit konsistenten Retry-Fenstern
• Feinabstimmung: erhöhe Limits für bekannte gute Clients, senke für offensichtliche Automatisierung

Schreibe Regeln in klarer Sprache auf: was begrenzt ist, das Zeitfenster (pro Sekunde/Minute/Tag), was passiert, wenn das Limit erreicht ist, und wie man eine höhere Quote anfragt.

Hole Hilfe, wenn Limits leicht umgangen werden, legitime Nutzer gesperrt werden und du das aus Logs nicht erklären kannst, Auth und Keys chaotisch sind (geteilte Tokens, fehlende User-IDs) oder du breitere Sicherheitsprobleme vermutest (offenliegende Secrets, Injection-Risiken, kaputte Access-Checks).

Wenn deine API als AI-generierter Prototyp startete und Throttling oder Auth wackelig wirkt, ist eine gezielte Behebung oft schneller als endloses Patchen. FixMyMess (fixmymess.ai) kann ein kostenloses Code-Audit durchführen und dann Rate Limiting, Authentifizierung und Security-Hardening reparieren, damit das Projekt in der Regel innerhalb von 48–72 Stunden produktionsreif ist.