Laravel-RateLimiter: So vermeidest du Race Conditions bei hohen Anfragen

RateLimiter in Laravel gehört zu den zuverlässigsten Werkzeugen, um API-Endpunkte vor Überlastung zu schützen. Doch was passiert, wenn 100 Anfragen gleichzeitig auf einen Endpunkt treffen, der auf fünf Anfragen pro Minute begrenzt ist? Die Standardlösung aus den offiziellen Laravel-Dokumenten versagt – und das liegt nicht an der Implementierung selbst, sondern an einem oft übersehenen Detail: Race Conditions.

Wer mit Laravel arbeitet, kennt das klassische Muster für die Ratenbegrenzung. Zunächst wird geprüft, ob die maximale Anzahl an Versuchen bereits erreicht ist. Falls nicht, wird der Zähler um eins erhöht und die Anfrage verarbeitet. Klingt simpel, doch unter hoher Last offenbart sich der Schwachpunkt dieses Ansatzes.

Wie der Race Condition entsteht

Die Logik scheint zunächst korrekt: Zwei Schritte – Prüfung und Erhöhung – werden nacheinander ausgeführt. Doch zwischen diesen Schritten existiert ein kritisches Zeitfenster, in dem andere Anfragen die gleiche, veraltete Information aus dem Cache auslesen können. Das Problem lässt sich am besten mit einem konkreten Beispiel verdeutlichen.

Stellen Sie sich vor, ein Endpunkt soll maximal fünf Anfragen pro Minute zulassen. Zehn Nutzer senden gleichzeitig eine Anfrage. Hier ist der Ablauf:

• Anfrage 1 liest den aktuellen Zählerstand aus dem Cache (0) und stellt fest, dass der Grenzwert noch nicht erreicht ist. Die Anfrage wird verarbeitet.
• Noch bevor Anfrage 1 den Zähler erhöht, liest Anfrage 2 ebenfalls den Zählerstand (0) aus. Auch sie passiert die Prüfung und wird verarbeitet.
• Dieser Prozess wiederholt sich, bis alle zehn Anfragen verarbeitet wurden – obwohl nur fünf hätten erlaubt sein sollen.

Der Grund liegt in der Trennung von Prüfung und Erhöhung. Beide Operationen greifen auf den Cache zu, doch keine der beiden ist atomar. Erst wenn beide Schritte in einer einzigen atomaren Operation zusammengefasst werden, lässt sich das Problem beheben.

Warum hit() die bessere Wahl ist

Laravels RateLimiter bietet zwei Methoden zur Handhabung von Zählern: hit() und increment(). Beide führen letztlich dieselbe Aufgabe aus – sie erhöhen den Zähler um einen bestimmten Wert. Der entscheidende Unterschied liegt in der Rückgabe: Während increment() den neuen Zählerstand zurückgibt, ist hit() eine vereinfachte Variante, die standardmäßig um eins erhöht.

Der Schlüssel zur Lösung des Problems liegt in der Nutzung der Rückgabewerte. Statt zunächst zu prüfen und dann zu erhöhen, wird der Zähler direkt erhöht und das Ergebnis sofort überprüft. So sieht die optimierte Version aus:

$attempts = RateLimiter::hit('send-message:'.$user->id);
if ($attempts > $maxAttempts) {
    return 'Zu viele Versuche!';
}
// Anfrage verarbeiten

Bei dieser Herangehensweise wird jede Anfrage einzeln behandelt. Die ersten fünf Anfragen erhalten Zählerstände von 1 bis 5 und werden akzeptiert. Alle weiteren Anfragen erhalten Werte größer als fünf und werden abgelehnt. Der entscheidende Vorteil: Der Cache-Zugriff ist nun atomar. Jede Anfrage erhält einen eindeutigen, erhöhten Zählerstand zurück, der sofort überprüft werden kann. Es gibt kein Zeitfenster mehr, in dem veraltete Daten ausgelesen werden können.

Warum die atomare Operation entscheidend ist

Unter der Haube nutzt Laravel für die Zählerverwaltung Redis oder einen anderen Cache-Speicher. Redis bietet mit dem Befehl INCR eine atomare Inkrementierungsoperation. Das bedeutet: Selbst bei tausend gleichzeitigen Anfragen wird jede Erhöhung des Zählers in einer einzigen, ununterbrechbaren Operation durchgeführt. Keine zwei Anfragen können denselben alten Zählerstand auslesen, bevor eine von ihnen ihn erhöht.

Die Methode hit() ist im Grunde ein Wrapper um diese atomare Operation. Sie gibt den neuen Zählerstand zurück, der sofort für die Überprüfung genutzt werden kann. Im Gegensatz dazu führt die Methode tooManyAttempts() eine separate Leseoperation durch, die nicht atomar ist. Erst danach wird der Zähler erhöht – und genau hier liegt die Schwachstelle.

Ein weiterer Vorteil dieser Herangehensweise ist die Transparenz des Zählerstands. Während die ursprüngliche Methode den Zähler um einen Wert erhöhen konnte, der über dem erlaubten Maximum lag (z. B. sechs, obwohl nur fünf erlaubt waren), sorgt die neue Methode dafür, dass jede Anfrage, die den Grenzwert überschreitet, sofort abgelehnt wird. Der Zählerstand mag hoch erscheinen, doch nur die ersten fünf Anfragen wurden tatsächlich verarbeitet.

Grenzen des Ansatzes

Auch wenn diese Lösung die meisten Race Conditions verhindert, gibt es Situationen, in denen sie nicht ausreicht. Eine wichtige Einschränkung betrifft verteilte Systeme, bei denen Redis in mehreren Regionen betrieben wird. In diesem Fall ist der Zähler nicht zentralisiert, und jede Region verwaltet ihren eigenen Zählerstand. Wenn ein Angreifer Anfragen an alle Regionen gleichzeitig sendet, könnte jede Region für sich genommen bis zu fünf Anfragen zulassen – insgesamt also mehr als die erlaubte Rate.

Für Anwendungen wie captchaapi.eu, die auf einem einzigen Redis-Server in Nürnberg laufen, ist diese Lösung ausreichend. Wer jedoch eine globale Ratenbegrenzung benötigt, muss auf komplexere Mechanismen wie Token-Buckets oder Sliding-Window-Logs zurückgreifen, die eine zentrale Koordination erfordern.

Ein weiteres Problem sind rotierende IP-Adressen. Selbst wenn die Ratenbegrenzung pro IP funktioniert, kann ein Angreifer mit einem Botnet oder Wohnproxys die Begrenzung umgehen, indem er ständig neue IPs verwendet. In solchen Fällen ist eine zusätzliche Schutzschicht wie eine Proof-of-Work-Challenge erforderlich.

Fazit: Ein kleiner Code, große Wirkung

Race Conditions in Laravel RateLimiter sind kein Zeichen von Schwäche, sondern ein häufig übersehener Aspekt von Nebenläufigkeit. Die Lösung ist überraschend einfach: Statt zwei getrennte Operationen für Prüfung und Erhöhung durchzuführen, wird die Erhöhung in einer atomaren Operation mit sofortiger Rückgabe des neuen Zählerstands kombiniert.

Diese Methode ist nicht nur effizienter, sondern auch sicherer. Sie verhindert, dass unter Last mehr Anfragen durchkommen als erlaubt, und schützt so vor unnötigen Kosten für teure Operationen wie KI-Inferenzen oder externe API-Aufrufe. Für Entwickler, die mit hohen Anfragevolumen arbeiten, lohnt es sich, diesen Ansatz in die eigene Rate-Limiting-Strategie zu integrieren – bevor der erste Angriff mit 100 gleichzeitigen Anfragen das System überlastet.