Rate Limiting für E-Commerce-APIs: Login und Checkout schützen, ohne Kunden zu blockieren

Ein Limit für den gesamten Shop ist das falsche Limit

Rate Limiting schützt Verfügbarkeit, Kosten und sensible Geschäftsabläufe, doch eine einheitliche Regel kann selbst einen Ausfall verursachen. Eine fehlgeschlagene Anmeldung, das Lesen des Katalogs, eine Warenkorbänderung, das Einleiten einer Zahlung und eine Partnersynchronisierung verbrauchen unterschiedliche Ressourcen und haben unterschiedliche Folgen für Kunden. Dasselbe Zeitfenster, derselbe Zählschlüssel und dieselbe Aktion verwechseln Missbrauch, Kampagnenerfolg und legitimes Verhalten.

OWASP nennt den unbegrenzten Verbrauch von CPU, Speicher, Bandbreite, Datenspeicher und kostenpflichtigen Drittdiensten als API-Risiko. Operativ sollen Limits an die Geschäftsanforderungen angepasst werden, wobei manche Endpoints strengere Regeln brauchen. Es geht daher nicht um eine allgemeingültige Zahl. Benötigt werden Budgets, Identitäten, Prioritäten und Degradationswege, die Login und Checkout schützen, ohne den Einkauf störanfällig zu machen.

Inventar, Identitäten und Ausgangslage vorbereiten

Operationen nach tatsächlichem Aufwand klassifizieren

Erfassen Sie Routen, HTTP-Methoden, Authentifizierung, Abhängigkeiten und Kosten. Halten Sie fest, ob eine Operation Cache oder Datenbank liest, Zustand verändert, einen Anbieter aufruft, asynchrone Arbeit startet oder Last durch Seiten, Filter und Batches vervielfacht. Shopify beschreibt beispielsweise GraphQL-Limits nach Abfragekosten und einen Bucket, der Kapazität wiederherstellt.

Schlüssel wählen, die das Subjekt abbilden

Die Ausgangsmatrix ordnet jeder Klasse vier Elemente zu: Wer wird gezählt, was verbraucht Budget, welche Aktion folgt und wie erholt sich der Client? Eine IP-Adresse ist ein nützliches Signal, aber keine zuverlässige Identität. Firmen, Mobilfunkkunden und Haushalte können sie teilen, während Bots ihren Verkehr verteilen. Kombinieren Sie, soweit angemessen, IP, Session, Konto, Client-ID, Mandant und API-Zugangsdaten. Pseudonymisieren Sie sensible Kennungen und begrenzen Sie die Schlüsselanzahl.

• Login: Budgets je IP und pseudonymisierter Kontokennung, mit getrennt gezählten Fehlschlägen.
• Katalog: elastisches Budget für cachebare Lesezugriffe, getrennt von aufwendiger Suche, Export und tiefer Paginierung.
• Warenkorb: Session- oder Nutzerschlüssel und unterschiedliche Budgets für Lesen und Mutationen.
• Checkout: Session-, Konto- und Risikokontext mit reservierter Kapazität für laufende Vorgänge.
• Integrationen: Schlüssel je Client, Shop oder Mandant sowie Grenzen für Parallelität und Kosten.

Jedem Ablauf eine eigene Policy geben

Login und Wiederherstellung: das Missbrauchssignal zählen

Beobachten Sie beim Login Gesamtversuche und fehlgeschlagene Ergebnisse getrennt. Cloudflare dokumentiert getrennte Ausdrücke für Zählung und Abwehr; auch Antwortcodes des Backends können in die Zählung einfließen. So entsteht eine Staffelung aus Beobachtung, Verzögerung, zusätzlicher Prüfung und angemessener vorübergehender Sperre, statt sofort die gesamte Navigation zu verbieten. Meldungen dürfen keine Konten verraten, und legitime Nutzer brauchen einen zugänglichen Weg. Passwortwiederherstellung, OTP-Versand und Kontoanlage erhalten eigene Budgets, weil Missbrauch und externe Kosten anders ausfallen.

Katalog: Nachfrage aufnehmen und teure Abfragen isolieren

Produkt- und Kategorieseiten müssen Kampagnen und Blitzverkäufe verkraften. Nutzen Sie Cache und Edge-Auslieferung, erlauben Sie von der Ausgangslage gestützte Bursts und begrenzen Sie teure Arbeit enger: kombinatorische Suche, nicht indexierte Sortierung, Exporte, wiederholtes Scraping, tiefe Seiten und übergroße Batches. Begrenzen Sie außerdem Parametergröße, Elementanzahl und Laufzeit. OWASP macht deutlich, dass Häufigkeit nur ein Teil der Ressourcenkontrolle ist. Identifizierte Bots und autorisierte Partner können ausdrückliche Regeln erhalten, aber keinen unbegrenzten Bypass.

Warenkorb: Mutationen schützen, ohne Absichten zu verlieren

Das Lesen des Warenkorbs unterscheidet sich von Hinzufügen, Entfernen, Neuberechnen einer Aktion oder Abfragen von Versandoptionen. Begrenzen Sie Mutationen je Session und machen Sie Vorgänge idempotent, wenn sie nach einem Timeout wiederholt werden können. Bewahren Sie unter Last den gespeicherten Zustand und verschieben Sie nur unwesentliche Berechnungen. Leeren Sie den Warenkorb nicht und machen Sie aus einem Retry keine doppelte Menge. Prüfen Sie vom Frontend erzeugte Bursts: Doppelklicks, Retries ohne Backoff und mehrfach aufrufende Komponenten wirken manchmal wie Angriffe.

Checkout: Kapazität reservieren und gezielt degradieren

Der Checkout braucht von Katalog und Backoffice getrennte Budgets und Warteschlangen. Trennen Sie Sessionstart, Adressprüfung, Versandangebot, Rabatt, Anlegen der Zahlungsabsicht und Statusabfrage. Bereits laufende Vorgänge haben Vorrang vor neuer Arbeit; optionale Dienste dürfen degradieren, ohne wesentliche Schritte zu blockieren. Idempotenz, Authentifizierung und Betrugsprüfung bleiben eigenständige Kontrollen und werden vom Limiter nicht ersetzt.

Vermeiden Sie eine globale Regel allein nach IP. Ein Käufer in einem gemeinsam genutzten Netzwerk darf seine Zahlung nicht verlieren, weil andere Personen stöbern. Kombinieren Sie Signale, setzen Sie möglichst gestufte Prüfungen ein und halten Sie einen Supportweg offen. Legen Sie vorab fest, was erneut versucht werden darf und wann der vorhandene Transaktionsstatus abzurufen ist.

Integrationen: Budget nach Client, Kosten und Parallelität

APIs für ERP, PIM, Marktplatz und Logistik benötigen Quoten je Zugangsdaten und Mandant, Parallelitätsgrenzen und Warteschlangen für schwere Arbeit. Gewichten Sie Operationen nach Aufwand, statt einen Punktabruf mit einer großen Synchronisierung gleichzusetzen. Wenn ein Anbieter Budgetinformationen liefert, nutzen Sie sie zur Taktung. Shopify gibt beispielsweise GraphQL-Abfragekosten und Throttle-Status zurück. Bei einem vorgelagerten Limit helfen begrenztes Backoff mit Jitter und beachtete Zeithinweise; parallele Retries würden den Druck verstärken.

Edge, Gateway und Anwendung koordinieren

Die Edge fängt offensichtlichen Missbrauch ab und schützt den Origin. Das Gateway setzt Client- und Mandantenquoten um. Die Anwendung kennt Konto, Ergebnis und fachliche Kosten. Worker und Datenbanken begrenzen Parallelität, Timeouts und Kapazität. Entscheidungen sollen zusammenpassen, ohne Zähler blind zu duplizieren. Dokumentieren Sie für jede Regel Vorrang, Schlüssel, Fenster, Aktion, Verantwortlichen und Notbetrieb.

Teilen Sie Zustand nur, wenn Korrektheit ihn erfordert. Ein verteilter Limiter kann eine zum Risiko passende Konsistenz verwenden, sein Fehlermodus muss jedoch bewusst gewählt sein. Beim Login kann Unsicherheit zusätzliche Prüfung bedeuten, während eine gecachte Kataloglesung weiterlaufen kann. Schützen Sie auch den Zählerspeicher vor Sättigung und unbegrenztem Schlüsselwachstum.

Eine vom Client nutzbare 429-Antwort liefern

RFC 6585 definiert 429 Too Many Requests für zu viele Anfragen in einem Zeitraum. Die Darstellung sollte den Zustand erklären und kann Retry-After enthalten; wie ein Server Nutzer erkennt oder Anfragen zählt, schreibt die RFC nicht vor. Kontrollierte APIs liefern einen stabilen Body mit Maschinencode, Limitbereich und Korrelations-ID, ohne Betrugssignale preiszugeben. Verwenden Sie Retry-After, wenn die Wartezeit zuverlässig ist, und verhindern Sie Caching.

Im Shop wird nur die betroffene Aktion deaktiviert; Eingaben und Warenkorb bleiben erhalten, automatische Schleifen werden vermieden und die Meldung bleibt verständlich. Server-Clients verwenden begrenzte Versuche, Backoff und Jitter. Bei einem extremen Angriff kann die Antwort auf jede Anfrage selbst Ressourcen verbrauchen; RFC 6585 erlaubt deshalb andere Schutzmaßnahmen. Netzwerk- und Kapazitätskontrollen bleiben erforderlich.

Mit schrittweisem Rollout und realistischen Tests abstimmen

Beginnen Sie im Beobachtungsmodus: Protokollieren Sie, welche Regel gehandelt hätte, ohne zu blockieren. Erstellen Sie Ausgangswerte nach Route, Identität, Land, Kanal, Zeit, Kampagne und Client-Version. Trennen Sie echte Käufer, bekannte Automatisierung, unbekannten Verkehr und Frontend-Fehler. Leiten Sie Schwellen aus internen Verteilungen und gemessener Kapazität ab. Testen Sie Spitzen, gemeinsames NAT, Retries, Cookieverlust, Kampagnen, langsame Warteschlangen und den Ausfall des Zählerspeichers.

1. Verteilen Sie eine Policy auf eine Endpoint-Klasse und einen kontrollierten Verkehrsanteil.
2. Verbinden Sie Limiter-Entscheidung, Origin-Antwort und Kundenweg über eine gemeinsame Kennung.
3. Erweitern Sie schrittweise mit ablaufenden Ausnahmen und einem getesteten Notschalter.
4. Prüfen Sie Regeln nach Änderungen an Frontend, Katalog, Kampagne, Anbieter oder Architektur.

Schutz und geschützte Kunden messen

Das Dashboard zeigt zugelassene, verzögerte, geprüfte und abgewiesene Anfragen je Policy; den 429-Anteil in offenbar legitimen Sessions; Login-Erfolg nach Prüfung; Warenkorb- und Checkout-Abbruch nach einer Entscheidung; Latenz, Origin-Sättigung und Anbieterkosten; Beachtung von Retry-After; sowie Verfügbarkeit und Latenz des Limiters. Segmentieren Sie nach Route, Schlüssel, Aktion und Version ohne unkontrollierte hochkardinale Labels.

Kombinieren Sie technische Alarme mit Geschäfts- und Supportsignalen. Niedrigere Origin-Last ist kein Erfolg, wenn blockierte Kunden oder Wiederherstellungstickets zunehmen. Das Runbook erklärt, wie Angriff, zu aggressive Regel, Clientfehler und langsame Abhängigkeit unterschieden werden; wer Regeln ändern darf; wann eine Ausnahme abläuft; welche Logs bleiben; und wie eine Entscheidung ohne unnötige Datensammlung rekonstruiert wird.

Das Betriebs-Runbook vor dem Start

Prüfen Sie für jeden Endpoint Verantwortlichen, Kostenklasse, Identität, Budget, Aktion, Antwort und Dashboard. Testen Sie verteilte falsche Zugangsdaten, viele Konten hinter einer IP, Katalog-Scraping, doppelte Warenkorbmutationen, Zahlungstimeouts, Partner-Batches, Verlust des Zählerspeichers und eine plötzlich reduzierte Anbieterquote. Bestätigen Sie, dass Kunden in jedem Szenario fortfahren oder den Zustand wiederherstellen können.

Gutes E-Commerce-Rate-Limiting ist eine Resilienz-Policy und keine einzelne Schranke. Es unterscheidet Abläufe, bewahrt Checkout-Kapazität, macht Clients kooperativ und misst Fehlentscheidungen neben blockiertem Verkehr. Unterstützung bei Gateways, Observability und zuverlässigen Abläufen bieten unsere Leistungen für E-Commerce und Systeme. Für die Prüfung von Policies und Rollout kontaktieren Sie AE Digital Agency.