Rate Limiting

Definition

Rate Limiting ist eine Verkehrsmanagement-Kontrolle, die eine Obergrenze dafür durchsetzt, wie häufig ein Client innerhalb eines spezifizierten Zeitfensters eine bestimmte Aktion ausführen kann. Wenn ein Client den Schwellenwert überschreitet, antwortet der Server mit einem Fehler — typischerweise HTTP 429 Too Many Requests — oder verwirft die überschüssigen Anfragen stillschweigend. Das Zeitfenster wird entweder nach einem festen Zeitplan zurückgesetzt (ein „Fixed Window”-Zähler) oder rollend (ein „Sliding Window”-Zähler), wobei Sliding Windows eine sanftere Durchsetzung bieten, die Burst-Ausnutzung an Fenstergrenzen verhindert^[1].

Rate Limiting ist eine der ältesten und am universellsten eingesetzten Web-Sicherheitskontrollen. Die OWASP (Open Web Application Security Project) empfiehlt sie als primäre Verteidigung gegen Brute-Force-Angriffe, Credential Stuffing und automatisierten Formularmissbrauch. Cloudflare bietet Rate Limiting als Funktion seines WAF-Produkts an, mit Regeln, die nach URL-Pfad, HTTP-Methode, IP-Adresse, Cookie-Wert und Anfrage-Header konfigurierbar sind. AWS WAF, Azure Front Door und Google Cloud Armor bieten gleichwertige Fähigkeiten.

Funktionsweise

Ein Rate Limiter pflegt einen Zähler für jede eindeutige Client-Kennung — am häufigsten die Quell-IP-Adresse, manchmal aber auch eine Konto-Kennung, ein API-Schlüssel oder ein Sitzungs-Cookie. Wenn eine Anfrage eintrifft, prüft der Server den aktuellen Zählerwert für diese Kennung. Liegt der Zähler unter dem Schwellenwert, wird die Anfrage zugelassen und der Zähler inkrementiert. Liegt der Zähler auf oder über dem Schwellenwert, wird die Anfrage mit einer 429-Antwort abgelehnt oder gemäß der konfigurierten Policy behandelt.

Die Zählerspeicherung wird typischerweise in Redis oder Memcached implementiert, um schnelle, verteilte Lookups über mehrere Server-Instanzen zu ermöglichen — eine Anforderung für horizontal skalierte Anwendungen. Die Cloudflare-Dokumentation beschreibt die Rate-Limiting-Durchsetzung auf der Edge-Netzwerkebene, wo Regeln angewendet werden, bevor Anfragen den Origin-Server erreichen, was die Lastreduktion über die globale Cloudflare-Infrastruktur verteilt.

Häufige Rate-Limiting-Parameter im Wettbewerbskontext umfassen:

• Stimmen pro IP pro Zeitfenster: Die häufigste Konfiguration. Beispiel: maximal 1 Stimme pro IP-Adresse pro 24-Stunden-Fenster.
• Stimmen pro Konto pro Wettbewerb: Auf Anwendungsebene mit der authentifizierten Nutzer-Konto-Kennung als Schlüssel durchgesetzt.
• Registrierungen pro IP pro Stunde: Auf den Konto-Erstellungs-Endpoint angewendet, um bot-getriebenes Konto-Farming zu verlangsamen.
• API-Aufrufe pro Token pro Minute: Relevant für Wettbewerbsplattformen, die eine öffentliche Voting-API bereitstellen.

Rate Limiting kann auch probabilistisch angewendet werden — beispielsweise mit strengeren Limits für Anfragen mit verhaltensbezogenen oder Fingerprint-Signalen, die Automatisierung nahelegen, und lockereren Limits für Sitzungen mit hochsicheren Mensch-Indikatoren.

Wo Sie ihm begegnen

Rate Limiting ist eine allgegenwärtige Kontrolle, die in praktisch jeder Webplattform vorhanden ist. Wettbewerbsbetreiber begegnen ihr am direktesten an drei Punkten: dem Stimmabgabe-Endpoint, dem Konto-Registrierungsformular und (sofern E-Mail-Bestätigung erforderlich ist) der E-Mail-Versand-Pipeline. API-getriebene Wettbewerbsintegrationen begegnen Rate Limits an den API-Endpoints der Plattform.

Für Endnutzer manifestiert sich Rate Limiting am sichtbarsten als HTTP-429-Fehler oder als plattformspezifische Meldung wie „Sie haben bereits abgestimmt” oder „Bitte warten Sie, bevor Sie erneut abstimmen”. Viele Plattformen implementieren Soft Rate Limiting — Anfrage akzeptieren, aber das Duplikat stillschweigend verwerfen — um die Existenz der Kontrolle nicht an potenzielle Missbraucher zu signalisieren.

Die Rate-Limiting-Dokumentation von Cloudflares WAF weist darauf hin, dass Rate-Limiting-Regeln während einer Analysephase auf Logging ohne Blockierung gesetzt und dann auf Blockierung umgestellt werden können, sobald der angemessene Schwellenwert kalibriert ist. Dieser zweiphasige Ansatz hilft Wettbewerbsbetreibern, das versehentliche Blockieren legitimer Stimmenwellen zu vermeiden^[2].

Praktische Beispiele

Ein Wettbewerb für Foodblogger-Auszeichnungen konfiguriert sein Voting-System mit einem 24-Stunden-Pro-IP-Rate-Limit. Während der letzten Wettbewerbswoche versucht ein Wähler, in schneller Folge 50 Stimmen von derselben Wohn-IP-Adresse abzugeben. Die erste Stimme wird akzeptiert; die folgenden 49 Anfragen erhalten eine 429-Antwort. Der Browser des Wählers zeigt eine Meldung an, die das Limit von einer Stimme pro Tag erklärt.

Eine SaaS-Wettbewerbsplattform, die hunderte gleichzeitiger Wettbewerbe hostet, verwendet Cloudflares Rate Limiting am Netzwerkrand. Ein Bot, der mit 10.000 Anfragen pro Minute auf einen Wettbewerb zielt, wird am Rand auf maximal 60 Anfragen pro Minute gedrosselt, wobei die überschüssigen Anfragen den Origin-Server nie erreichen. Die Logs des Origin-Servers zeigen nur den gedrosselten Verkehr, und die serverseitige CPU-Auslastung bleibt unbeeinträchtigt.

Ein OWASP-Sicherheitsreview einer maßgeschneiderten Wettbewerbs-Microsite eines Startups identifiziert das Fehlen von Rate Limiting am E-Mail-Bestätigungs-Resend-Endpoint als Schwachstelle — ein Angreifer könnte den Posteingang eines Opfers durch das Auslösen tausender Bestätigungs-E-Mails fluten. Das Review empfiehlt die Implementierung eines Rate Limits von 3 Resend-Anfragen pro E-Mail-Adresse pro Stunde, konsistent mit den OWASP-Brute-Force-Präventionsrichtlinien.

Verwandte Konzepte

Anomalie-Erkennung ist eine ausgereiftere Ergänzung zum Rate Limiting: Während Rate Limiting harte Schwellenwerte durchsetzt, identifiziert die Anomalie-Erkennung Abweichungen von einer gelernten Verhaltens-Baseline und fängt Betrugskampagnen ab, die knapp unter festen Limits bleiben. ASN-Diversität wird relevant, wenn Rate Limits pro IP angewendet werden und ein böswilliger Akteur Anfragen über viele IP-Adressen verteilt, um unter den Pro-IP-Schwellenwerten zu bleiben — die ASN-Level-Analyse erkennt das aggregierte Muster. reCAPTCHA v3 liefert einen verhaltensbezogenen Risiko-Score, der mit Rate Limiting kombiniert werden kann, um strengere Limits selektiv auf Sitzungen anzuwenden, die als potenziell automatisiert bewertet werden.

Einschränkungen / Hinweise

IP-basiertes Rate Limiting ist in Umgebungen mit Carrier-Grade NAT weniger effektiv, in denen eine einzelne öffentliche IP hunderte legitimer mobiler Teilnehmer repräsentieren kann. Ein Pro-IP-Rate-Limit von 1 Stimme pro 24 Stunden würde die meisten dieser Teilnehmer fälschlich am Abstimmen hindern. Deshalb muss Rate Limiting auf Wettbewerbsplattformen mit konto- oder cookie-basierter Deduplizierung kombiniert werden, wenn das mobile Publikum signifikant ist. Zusätzlich können zu aggressiv eingestellte Rate Limits die Erfahrung legitimer Wähler beeinträchtigen, die aus geteilten Netzwerken wie Universitäts-Campussen, Unternehmensbüros oder großen öffentlichen WLAN-Hotspots kommen^[3].

Quellen

1. Wikipedia — Rate limiting: https://en.wikipedia.org/wiki/Rate_limiting
2. Cloudflare — What is rate limiting: https://www.cloudflare.com/learning/bots/what-is-rate-limiting/
3. OWASP — Blocking Brute Force Attacks: https://owasp.org/www-community/controls/Blocking_Brute_Force_Attacks