Without rate limiting, any endpoint that accepts input can be hit as fast as the network allows — turning a login form into a brute-force target, or a search endpoint into a resource exhaustion vector.
What rate limiting actually prevents
- Credential stuffing and brute-force attacks against login endpoints.
- Resource exhaustion from a single client overwhelming expensive operations.
- Data scraping at a volume that wouldn't be possible for a genuine user.
- Abuse of costly third-party integrations billed per request, where an attacker could run up costs by hammering an endpoint that triggers external API calls.
Common algorithms
- Fixed window — simplest to implement, but allows bursts right at window boundaries (e.g. a full limit's worth of requests at the end of one window, then again immediately at the start of the next).
- Sliding window — smooths out the boundary issue, more accurate but slightly more complex to implement.
- Token bucket — allows controlled bursts while maintaining a steady average rate, commonly used for API rate limiting where some burst tolerance is desirable.
Where to apply limits
Different endpoints warrant different limits based on sensitivity and cost:
- Authentication endpoints need tight limits, since brute-force is the primary threat.
- Expensive or third-party-backed endpoints need limits reflecting actual cost, not just abuse prevention.
- General API traffic benefits from a broader baseline limit as a backstop against unexpected load.
Combine identifiers for reliable limiting
Limiting purely by IP address is easy to work around with distributed requests, and can also incorrectly penalize legitimate users behind shared IPs (corporate networks, mobile carriers using NAT). Combining IP-based limits with account or API-key-based limits gives more precise and harder-to-bypass protection.
Respond with clear signals
Returning a standard 429 Too Many Requests status with a Retry-After header lets well-behaved clients back off appropriately, rather than retrying immediately and compounding the problem.
Rate limiting isn't a substitute for proper authentication and authorization — it's a complementary control that limits how fast any gap in those can be exploited.