In 2022, a security researcher discovered that a popular social media platform’s password reset endpoint had no request limits. Using a simple script, they submitted 1,000 guesses against a six-digit OTP in under four minutes. The platform’s authentication system accepted every single request without complaint.
Thank you for reading this post, don't forget to subscribe!The math was brutal: a six-digit OTP has one million possible combinations. With no rate limiting, an automated attack could exhaust the entire keyspace in roughly 67 minutes. The researcher reported it responsibly. The company paid a significant bug bounty. But the same flaw applied against a less ethical target would have allowed account takeover at industrial scale.
This is precisely what rate limiting API security is designed to prevent. Without it, your API is an open invitation for brute force attacks, automated scraping, credential stuffing, and resource exhaustion and the consequences range from data breaches to complete service outages.
In this guide, you will learn exactly why rate limiting matters, what attacks it prevents, how different rate limiting techniques work, where implementations commonly fail, and what a production-ready rate limiting strategy actually looks like. Whether you are a developer building APIs, a security engineer reviewing architecture, or a bug bounty hunter looking for high-value misconfiguration findings this is the reference you need.
What is Rate Limiting?
Rate limiting is a control mechanism that restricts how many requests a client can make to a server within a defined time window.
At its core, it is a simple concept: you are allowed ten requests per minute. After that, you wait. The server enforces this by tracking incoming requests usually by IP address, user identity, API key, or some combination and rejecting or delaying requests that exceed the defined threshold.
In API security, rate limiting acts as the bouncer at the door. It does not care whether an individual request is legitimate or malicious. It cares about volume and frequency. When those cross a defined threshold, access is restricted buying time for detection, preventing system overload, and making automated attacks economically impractical.
A server responding to rate limit violations typically returns an HTTP 429 Too Many Requests status code, often with a Retry-After header indicating when the client can try again.
The mechanism sounds simple. Implementing it correctly is not.
Why Rate Limiting is Critical for API Security
Every modern application runs on APIs. Mobile apps, web frontends, IoT devices, third-party integrations they all communicate through API endpoints. Each of those endpoints is a potential target, and without rate limiting, each one is an uncapped resource that any actor on the internet can query without restriction.
Preventing Brute Force Attacks
A brute force attack works by trying many possible values until the correct one is found passwords, OTPs, account numbers, voucher codes. The attack requires volume: hundreds, thousands, or millions of attempts.
Without rate limiting, a login endpoint accepting an attacker’s automated requests at full server capacity might process 500 guesses per second. Even against a strong eight-character alphanumeric password, that becomes computationally feasible with modern tooling. With rate limiting set to five attempts per minute, the same attack would take thousands of years.
Rate limiting does not make brute force mathematically impossible. It makes it economically and practically impractical which is the realistic security goal.
Stopping API Abuse and Scraping
Data scraping through APIs is one of the most common forms of API abuse. Competitors scrape product catalogs and pricing. Bad actors scrape user profiles, contact data, and email addresses. Aggregators scrape proprietary data at scale and republish it.
Without rate limiting, a scraper can iterate through your entire user database by incrementing an ID parameter, or walk through every page of your product catalog, in hours. With rate limiting applied at both the authenticated-user level and the endpoint level, the time required to extract meaningful data becomes prohibitive.
Protection Against Denial of Service
A Denial of Service (DoS) attack floods a target with requests until it cannot respond to legitimate traffic. API endpoints without rate limiting are trivially exploitable for this: a single machine sending requests as fast as possible can generate enough load to degrade or take down a service.
Rate limiting caps the contribution any single source can make to total server load. Combined with connection limits and traffic shaping, it is a foundational layer of DoS resilience not a complete solution, but a necessary one.
Limiting Resource Exhaustion
Some API operations are expensive: database queries that join multiple tables, AI inference calls, PDF generation, video transcoding. Without rate limiting on these endpoints specifically, a single user or a small group of automated clients can consume compute resources intended for your entire user base.
Rate limiting protects not just availability, but operating cost. An unmetered AI API endpoint, for example, is a financial liability as much as a security one.
Real-World Attack Scenarios (Core Section)
Understanding the abstract risk is one thing. Seeing it in concrete scenarios is what drives home why rate limiting API security belongs in every production system from day one.
Brute Force Login Attacks
A login endpoint accepts a username and password. The server checks credentials, returns a token on success, and a 401 on failure. Without rate limiting, an attacker submits automated requests using a wordlist of commonly used passwords against a target email address.
This is a credential stuffing scenario when using known breached passwords, or a pure brute force scenario when using a wordlist. With no rate limiting, the attack runs limited only by the attacker’s bandwidth and the server’s capacity to process requests. Even with account lockout after N failures, a distributed attack spreading attempts across many accounts can avoid triggering lockout on any single one.
Impact: Account takeover. Unauthorized access to personal data, financial information, or administrative functions.
OTP and Authentication Code Abuse
Password reset flows, SMS verification, two-factor authentication codes, and email magic links all use short numeric or alphanumeric codes with limited keyspaces. A six-digit numeric OTP has one million possible values. An eight-digit alphanumeric code has tens of billions but if the window is 15 minutes and the server accepts unlimited guesses, the math changes dramatically in the attacker’s favor.
Unauthenticated endpoints that verify OTPs such as password reset confirmation are high-priority targets because they require no existing session or credential. The only barrier is guessing a short code.
Impact: Account takeover without knowing the victim’s password. Password reset hijacking. 2FA bypass.
API Scraping and Enumeration
Public-facing APIs that return user information, product data, or any enumerable resource are vulnerable to systematic extraction. An attacker sends sequential requests: /api/user/1, /api/user/2, /api/user/3, iterating until they have collected thousands of records.
This is an IDOR (Insecure Direct Object Reference) vulnerability exploited at scale, but it is also a rate limiting failure. Even if authorization checks prevent cross-user access, legitimate API endpoints with no rate limits can be queried faster than any manual user would ever need.
Impact: Mass data extraction. PII harvesting for phishing or identity fraud. Intellectual property theft. Regulatory violations (GDPR, CCPA).
Credential Stuffing Attacks
Credential stuffing uses breached username/password pairs from other services and tests them against your login endpoint. Because many users reuse passwords across services, a list of one million breached credentials might yield thousands of valid logins on an unrelated platform.
These attacks are particularly dangerous because each request uses a real credential there is no incorrect password pattern to flag. The only reliable signal is request volume and velocity.
Impact: Account takeover at scale. Fraud, unauthorized purchases, data theft. Reputational damage when reported by affected users.
What Happens Without Rate Limiting
Let us be specific. The absence of rate limiting in production systems creates concrete, measurable failure modes.
Unlimited request volume: Any authenticated or unauthenticated endpoint can be queried as fast as the attacker’s connection allows. A high-bandwidth server can receive hundreds of thousands of requests per minute from a single source.
Invisible enumeration: Without rate limiting, an attacker enumerating your user base or product catalog generates traffic that looks similar to a legitimate high-traffic event. It is difficult to distinguish without behavioral analysis on top of basic access logs.
Cascading resource exhaustion: Expensive operations queued by automated clients consume thread pools, database connections, and CPU time that other users need. This creates performance degradation and often a complete outage affecting legitimate users who did nothing wrong.
Regulatory exposure: If a rate-limiting failure allows mass extraction of user data, the event may qualify as a notifiable data breach under GDPR, CCPA, or other applicable regulations with penalties and mandatory notification requirements.
Bug bounty liability: Missing rate limiting on sensitive endpoints (login, OTP verification, password reset, account enumeration) is consistently reported as a valid finding often at medium to high severity by bug bounty researchers. A platform without rate limiting is a bounty-rich environment.
Types of Rate Limiting Techniques
Not all rate limiting is the same. The algorithm you choose affects how the system behaves under legitimate traffic spikes, burst requests, and sustained attacks.
Fixed Window
Divide time into fixed intervals (one minute, one hour). Count requests per client within each window. Reset the counter at the window boundary.
Example: Ten requests allowed per minute. At 0:59, a client sends their tenth request. At 1:00, the counter resets and they can send ten more.
Weakness: A client can send ten requests at 0:59 and ten more at 1:00 twenty requests in two seconds. This burst is not caught by fixed window counting.
Sliding Window
Instead of resetting at a fixed boundary, maintain a rolling time window. The allowed count is based on the actual requests in the last N seconds, calculated continuously.
Advantage: Eliminates the burst exploitation possible in fixed windows. More accurately represents sustained rate.
Trade-off: Requires more storage per client to maintain timestamps of recent requests.
Token Bucket
Each client has a “bucket” of tokens. Each request consumes one token. Tokens are replenished at a fixed rate (e.g., one token per second, up to a maximum of ten). If the bucket is empty, requests are rejected.
Advantage: Allows controlled bursting. A client who has been idle can accumulate tokens and send several requests in quick succession mimicking legitimate user behavior.
Use case: APIs where periodic bursts of activity are normal, like a user uploading a batch of files.
Leaky Bucket
Requests are placed into a queue (the “bucket”) that processes at a fixed rate. If the bucket is full, new requests are dropped.
Advantage: Provides consistent, smooth output regardless of input burst. Good for backend systems that need predictable throughput.
Difference from token bucket: Token bucket allows bursts up to capacity. Leaky bucket smooths everything to a constant rate.
How Attackers Try to Bypass Rate Limiting
Understanding bypass techniques helps developers build rate limiting that actually holds under adversarial conditions. This is educational the goal is to inform better implementations.
IP Rotation
Basic rate limiting tied only to IP address is defeated by rotating through many source IPs. Attackers use residential proxy networks, cloud instances, or botnet infrastructure to distribute requests across thousands of IP addresses each below the individual threshold.
Defense: Supplement IP-based limits with per-user limits (after authentication), device fingerprinting, behavioral analysis, and CAPTCHA challenges triggered by suspicious patterns.
Distributed Request Spreading
Similar to IP rotation: instead of one attacker sending many requests, coordinate many sources each sending few. The per-source volume never triggers a threshold.
Defense: Implement global endpoint rate limits (total requests per time period, regardless of source) alongside per-source limits. Monitor for correlated patterns across sources rather than only individual thresholds.
Header and Parameter Manipulation
Some rate limiting implementations key on headers like X-Forwarded-For or X-Real-IP, which can be spoofed by clients. An attacker who understands the keying mechanism can manipulate the identifier used for rate limit tracking.
Defense: Never trust client-supplied IP headers as the sole rate limiting key. Use the actual connection IP at the network layer as the primary identifier. Validate and sanitize any headers used in rate limit calculations.
Best Practices for Implementing Rate Limiting
This is where most implementations fail not because developers do not add rate limiting, but because they add it inconsistently or incorrectly.
Apply Rate Limiting at Multiple Layers
Rate limiting at the API gateway level catches volumetric abuse before it reaches your application. Rate limiting at the application level adds granularity based on user identity, operation type, and business logic. Both are necessary. Gateway-level limits catch infrastructure attacks; application-level limits enforce business rules.
Use Layered Identifiers
Tier your rate limiting by what you know about the requester:
- Unauthenticated requests: IP address (most restrictive)
- Authenticated requests: User ID (allows the same user to come from multiple IPs while tracking their aggregate usage)
- API key requests: Key identifier (allows different products or partners to have different quotas)
Combining these prevents both the anonymous attacker and the compromised authenticated account from abusing your endpoints.
Apply Endpoint-Specific Limits
Your main data API and your password reset endpoint should not share the same rate limit. Password reset, OTP verification, and login endpoints should have the most restrictive limits. Read-only public endpoints can be more permissive. Write operations and expensive computations deserve their own, tighter limits.
Implement Adaptive Rate Limiting
Static thresholds do not account for changing traffic patterns. Adaptive rate limiting adjusts thresholds based on current system load, detected anomalies, and behavioral signals. Under normal conditions, a user might get 100 requests per minute. Under sustained unusual volume across many users, limits automatically tighten.
This is more complex to implement but significantly more effective against sophisticated, slow-burn attacks that deliberately stay under static thresholds.
Return Informative but Non-Exploitable Errors
When a rate limit is hit, return HTTP 429 with a Retry-After header indicating when the client can try again. Do not include information about the exact limit threshold in the response body that information helps attackers calibrate their attack to stay just below limits.
Log Rate Limit Events and Alert on Anomalies
A client hitting the rate limit once is not interesting. A client hitting the rate limit repeatedly across multiple endpoints over an extended period is a strong signal of automated abuse. Rate limit event logs should feed into your security monitoring and alerting system, not just sit in access logs.
Tools and Technologies for Rate Limiting
You do not have to build rate limiting from scratch. The ecosystem of tools is mature.
API Gateways
AWS API Gateway, Kong, Apigee, Azure API Management: All include configurable rate limiting as a native feature. Policies can be applied globally, per API, per method, per consumer group, or per API key. Gateway-level enforcement happens before your application code runs reducing load on downstream systems.
Kong: Particularly powerful for self-hosted setups. Supports fixed window, sliding window, and custom algorithms through plugins.
CDN and WAF Solutions
Cloudflare Rate Limiting: Rule-based rate limiting at the CDN layer, before traffic reaches your origin. Supports matching on URL patterns, HTTP methods, request headers, and request body characteristics. Bot management add-on provides behavioral analysis beyond simple counting.
AWS WAF: Rate-based rules that count requests matching specific conditions and block sources that exceed thresholds over a five-minute window.
Akamai, Fastly: Enterprise CDN providers with sophisticated rate limiting and DDoS mitigation at the network edge.
Backend Libraries
Python: slowapi (FastAPI/Starlette), Flask-Limiter — both support Redis as a backend for distributed rate limit state.
Node.js: express-rate-limit for basic setups, rate-limiter-flexible for production-grade multi-strategy implementations with Redis backing.
Java/Spring: Spring Cloud Gateway supports route-level rate limiting with Redis integration out of the box.
Redis: The preferred state backend for distributed rate limiting. Fast, atomic operations make it reliable for tracking request counts across multiple application instances without race conditions.
Rate Limiting Techniques Comparison Table
| Technique | Pros | Cons | Best Use Case |
|---|---|---|---|
| Fixed Window | Simple to implement; low memory overhead | Allows burst at window boundary | Low-sensitivity public endpoints |
| Sliding Window | Accurate rate tracking; no boundary burst | Higher memory per client | Sensitive endpoints; authenticated APIs |
| Token Bucket | Allows natural burst; smooths traffic | More complex implementation | User-facing APIs; mobile app backends |
| Leaky Bucket | Predictable, smooth output; good backpressure | Does not allow burst; drops excess | Backend processing queues; payment flows |
| Adaptive Limiting | Responds to real conditions; harder to game | Complex to tune; requires monitoring | High-traffic production systems |
CyberSamir Expert Tip
The most common rate limiting failure we see in security assessments is not the absence of rate limiting it is inconsistency.
A team adds rate limiting to their login endpoint (correctly) and forgets to apply it to password reset, OTP verification, or the “check if this email exists” endpoint. Attackers do not go through the front door when the side door is open.
Before considering rate limiting “done,” map every endpoint your application exposes and ask three questions about each one:
- What is the maximum number of times a legitimate user would ever call this in one minute?
- What is the damage if an attacker calls this 10,000 times?
- Does my current rate limiting configuration reflect both of those answers?
If your OTP verification endpoint allows 100 requests per minute because that is the platform default, and the OTP is six digits, that is a security failure regardless of whether the login endpoint is locked down.
Also: test your rate limiting as part of your security regression suite. Rate limits get accidentally removed during framework migrations, configuration changes, and deployment pipeline updates. A test that confirms a 429 response after N+1 requests catches these regressions before attackers do.
Key Takeaways
- Rate limiting API security is not optional infrastructure it is a foundational security control without which brute force, scraping, credential stuffing, and DoS attacks become trivially executable.
- The absence of rate limiting on OTP and password reset endpoints is one of the most consistently found and rewarded vulnerabilities in bug bounty programs.
- Different rate limiting algorithms (fixed window, sliding window, token bucket, leaky bucket) have different trade-offs the right choice depends on your traffic patterns and sensitivity requirements.
- Rate limiting should be applied at multiple layers: CDN/edge, API gateway, and application level each catches different attack patterns.
- Keying on IP address alone is insufficient. Production rate limiting requires per-user, per-key, and per-endpoint dimensions.
- Bypass techniques (IP rotation, distributed requests, header manipulation) are well-known implementations must account for them with behavioral analysis and multi-dimensional identifiers.
- Redis is the standard backend for distributed, stateful rate limiting across multiple application instances.
- Log rate limit violations and alert on sustained patterns a single 429 is noise; repeated 429s across endpoints is a security signal.
- Test rate limiting explicitly in your security regression suite to catch accidental removal during deployments.
Conclusion
Rate limiting is one of those security controls that developers often deprioritize because it is not visible, it is not exciting, and it does not directly build product features. Until someone runs a brute force attack against an unprotected OTP endpoint, or scrapes your entire user database overnight, or submits enough requests to an expensive endpoint to multiply your cloud bill by ten.
The most powerful thing about rate limiting API security is its asymmetric impact: it costs very little to implement correctly and costs enormously when absent. A few hours of implementation work applying rate limiting at the gateway, tuning per-endpoint thresholds, keying on the right identifiers, and testing with explicit regression cases can close vulnerabilities that would otherwise take days of incident response to contain.
Every API endpoint you expose is a surface. Rate limiting is what controls how aggressively that surface can be probed. Build it in from the start, apply it consistently across every endpoint that matters, test it explicitly, and monitor it continuously.
The attacks described in this guide are not theoretical. They are running against production APIs right now, against teams that decided rate limiting could wait.
Do not let yours be one of them.
Internal Links:
