Rate limiting caps how many requests a client can send to an API, login form, or application endpoint within a fixed time window, and it's the difference between a service that degrades gracefully under load and one that falls over during a credential-stuffing attack or a scraping run. A typical rule might allow 100 requests per minute per IP address or 1,000 requests per hour per API key, with anything beyond that threshold rejected via an HTTP 429 "Too Many Requests" response. Without it, a single misconfigured script or a coordinated attacker can fire tens of thousands of requests per second at a login endpoint, a password-reset flow, or a pricing API — exhausting compute, inflating cloud bills, and in several documented breaches, exposing entire customer databases to automated scraping. Rate limiting sits alongside authentication and input validation as a baseline control, and it's called out by name in the OWASP API Security Top 10 under API4:2023, Unrestricted Resource Consumption.
How Does Rate Limiting Actually Work?
Rate limiting works by counting requests against a defined key — typically an IP address, user ID, API key, or session token — over a rolling or fixed time window, then rejecting, delaying, or queuing requests once a client crosses the configured threshold. The server (or a reverse proxy, API gateway, or CDN sitting in front of it) maintains a counter for each key, increments it on every request, and compares the count to the limit before the request reaches application logic. When the limit is exceeded, the response usually carries a 429 status code along with a Retry-After header telling the client how many seconds to wait, plus X-RateLimit-Limit and X-RateLimit-Remaining headers so well-behaved clients can self-throttle before hitting the wall. Nginx's limit_req module, AWS API Gateway's usage plans, and Cloudflare's rate limiting rules all implement variations of this same counting logic, just at different points in the request path.
What Are the Most Common Rate Limiting Algorithms?
The four most common algorithms are fixed window, sliding window, token bucket, and leaky bucket, and each one trades burst tolerance against implementation complexity. Fixed window counters reset every N seconds (e.g., 60 requests per 60-second window) but allow a client to send 60 requests at :59 and another 60 at :01, effectively 120 in two seconds — a well-known edge case. Sliding window logs smooth that out by tracking a rolling count across overlapping windows. Token bucket is the industry default for APIs: a bucket holds, say, 50 tokens, refills at 10 tokens per second, and each request consumes one token, which lets bursts through up to the bucket size while still enforcing a steady average rate. Leaky bucket works similarly but processes requests at a constant outflow rate regardless of burst size, which is why it's favored for traffic shaping on payment and messaging systems where consistent throughput matters more than burst tolerance.
Why Does Missing Rate Limiting Lead to Real-World Breaches?
Missing rate limiting has directly enabled some of the largest API-driven data exposures on record because it turns a single authorized query into an unlimited scraping engine. In the Optus breach disclosed in September 2022, an internet-facing API endpoint required no authentication and had no rate limiting on request volume, letting an attacker iterate through sequential customer identifiers and pull records for roughly 9.8 million current and former customers, including passport and driver's license numbers. Panera Bread's 2018 exposure followed a similar pattern: an unauthenticated API endpoint returning customer order data — names, emails, addresses, partial card numbers — could be queried repeatedly with no throttling, and a security researcher demonstrated that automated requests could harvest an estimated 37 million records before the company acted. On the account-takeover side, Akamai's State of the Internet research recorded roughly 193 billion credential-stuffing attempts globally in 2020, a volume that only works economically for attackers because most login endpoints allow far more authentication attempts per minute than any legitimate user would ever need.
What's the Difference Between Rate Limiting and Throttling?
Rate limiting rejects requests outright once a client crosses the threshold, while throttling slows requests down — queuing or delaying them — rather than dropping them, and production systems typically run both together. A checkout API might throttle requests between 80 and 100 per minute per user by adding artificial latency, then hard rate-limit and return a 429 above 100. This layering matters for user experience: a hard cutoff on every endpoint punishes legitimate traffic spikes (a product launch, a viral social post) as harshly as an attack, whereas throttling first gives real users a slower-but-working experience while still capping the ceiling an attacker can reach. Stripe's public API documentation, for example, describes exactly this two-tier model — soft slowdowns before a hard per-second cap — as the reason its checkout endpoints stay available during traffic surges.
How Do You Choose the Right Rate Limits for Different Endpoints?
The right limit comes from baselining normal traffic per endpoint and then applying materially tighter thresholds to sensitive operations than to read-only ones. A login endpoint might allow 5 failed attempts per account per 15 minutes before triggering a CAPTCHA or temporary lockout — tight enough to blunt credential stuffing but loose enough to tolerate a user who mistypes a password twice. A password-reset endpoint often gets an even stricter limit, such as 3 requests per hour per account, since it's a common target for enumeration attacks that confirm which email addresses have active accounts. A general-purpose read-only API serving product catalog data can tolerate 1,000+ requests per hour per key because the abuse potential is lower and legitimate integrations (mobile apps, partner systems) need headroom. Setting every endpoint to the same generic limit is one of the most common rate-limiting mistakes: OWASP's API4:2023 guidance specifically calls out the failure to apply resource-consumption limits per endpoint, per operation cost, and per client tier as a root cause of unrestricted resource consumption incidents.
How Safeguard Helps
Safeguard helps security teams find and fix rate-limiting gaps before they become breach headlines. Griffin AI triages exposed API endpoints and login flows across your codebase and flags the ones lacking throttling controls, prioritized by whether the vulnerable code path is actually reachable from an untrusted entry point rather than dead code — so teams aren't chasing findings that can't be exploited. Safeguard's SBOM generation and ingestion capabilities also surface which API frameworks and gateway libraries are in use, making it possible to correlate missing rate-limiting middleware with the specific services that need it. When a fix is available — adding a rate-limiting decorator, wiring in a gateway policy, or bumping a vulnerable dependency — Safeguard can open an auto-fix pull request directly, cutting the time between detection and remediation from weeks to hours.