API Rate Limiting: Protecting Against Abuse and Brute Force
Rate limiting is often treated as a performance concern. It is just as much a security control. Without it, attackers can brute force passwords and one-time codes, scrape your data, run up your bills and take your service down.
Endpoints that need limits most
- Login, signup and password reset: brute force and credential stuffing.
- One-time code verification: six-digit codes can be brute forced quickly without limits.
- Endpoints that send email or SMS: abuse costs you money and can get your domain flagged.
- Endpoints calling paid APIs, including AI models: unbounded usage becomes an unbounded bill.
- Search, export and listing endpoints: scraping and expensive queries.
- Invite and referral endpoints: spam and reward abuse.
Common algorithms
| Algorithm | How it works | Notes |
|---|---|---|
| Fixed window | Count requests per minute window | Simple, but bursts at window edges |
| Sliding window | Count over a rolling period | Smoother, slightly more complex |
| Token bucket | Tokens refill steadily, requests spend tokens | Allows controlled bursts |
| Leaky bucket | Requests processed at a fixed rate | Smooths traffic |
For most APIs, a sliding window or token bucket stored in a fast shared store like Redis works well.
What to key limits on
Use several dimensions together:
- Per account or API key, for authenticated endpoints.
- Per target identifier, such as the email being logged into or reset, to stop distributed attacks on one account.
- Per IP, as a coarse layer, accepting that attackers rotate IPs.
- Per organisation, for fair use in multi-tenant products.
Common bypasses
- Rotating IPs via proxies, when limits are only per IP.
- Spoofed headers like
X-Forwarded-For, when the app trusts them from any client. Only trust them from your own proxy. - Case and format variations, such as
[email protected]vs[email protected], or adding spaces. Normalise identifiers before counting. - GraphQL batching and aliases, sending many attempts in one request.
- Race conditions, sending many requests simultaneously before the counter updates. Use atomic increments.
- Alternative endpoints, like a mobile API or old version without limits.
Responding to limits
- Return
429 Too Many Requestswith aRetry-Afterheader. - For authentication, consider progressive delays and challenges rather than hard lockouts, which attackers can abuse to lock out real users.
- Alert on sustained limit hits, which often indicate an attack.
Limits are not a substitute for strong design
Six-digit codes should also expire quickly and be invalidated after several failures. Expensive operations should be paginated and bounded. Rate limits reduce risk; good design removes it.
Testing rate limits
SecurityInfinity tests sensitive endpoints for missing limits and common bypasses, including header spoofing, identifier normalisation and parallel requests. Start free.
Frequently asked questions
Can a WAF handle rate limiting?
A WAF or API gateway can enforce coarse limits, but application-level limits keyed on accounts and identifiers are needed for sensitive flows.
What limit should I set on login?
There is no universal value. A common approach is a handful of attempts per account per minute, with progressive delays and alerts.
Is a missing rate limit a vulnerability?
On sensitive endpoints like login, OTP verification or paid operations, yes. On general endpoints, it is more of a resilience issue.