Why Fixed-Window Rate Limiters Fail (And How to Fix Them with Math)

The Fixed-Window Counter rate limiting method has a significant flaw that can be exploited by attackers. This vulnerability allows bursts of requests during a brief period, bypassing the imposed limit. For example, if an endpoint permits 100 requests per minute, an attacker can fire 100 requests at 12:00:59, and then another 100 requests at 12:01:01.

Since the counter resets every minute, the server perceives the requests as legitimate, while in reality, the attacker has overloaded the backend with 200 requests in a 2-second window, potentially causing system failure or enabling attacks such as credential stuffing. To counter this issue, the Sliding Window Counter method can be employed, utilizing a continuously sliding window instead of a fixed clock reset.

This approach prevents boundary spikes by accurately accounting for request bursts. In contrast to the memory-intensive Sliding Window Log, the Sliding Window Counter maintains only two integers: the request count from the previous window and the count from the current window. By weighting the previous window based on the elapsed time in the current window, we estimate the total requests within the current window.

The time complexity remains constant at O(1), and the memory footprint is also optimized at O(1), requiring just two counter variables per IP. Implementing this sliding window counter in a Node.js middleware involves initializing a Map to track the state, calculating the estimated request count using the sliding weight formula, and comparing it with the allowed limit.

If the estimated requests exceed the limit, the request is denied; otherwise, the current count is incremented, and the record is updated.