Cybersecurity glossary
What is Rate Limiting?
Learn what rate limiting is, how request quotas stop brute force and API abuse, which dimensions to limit, and how to design limits that protect systems without blocking legitimate users.
Definition
Rate limiting is a control that restricts how many requests a client, user, IP, token, or other identity may make to a service within a time window, reducing abuse such as brute force, scraping, and resource exhaustion.
Why rate limiting matters
Public endpoints are programmable. Without quotas, attackers can guess passwords, spray OTPs, scrape catalogs, and trigger expensive reports until infrastructure or fraud costs spike.
Rate limiting makes abuse expensive by capping request velocity. It is not a complete bot defense, but missing limits are a common root cause of authentication and availability incidents.
How rate limiting works
Choose a key
Identify the client by IP, user ID, API key, device, or a composite identity.
Define a budget
Set allowed requests per window, optionally weighted by endpoint cost.
Track usage
Counters or token buckets record consumption in Redis, gateways, or app middleware.
Allow or reject
Under budget requests proceed; over budget receive 429/challenge/delay.
Return safe guidance
Include Retry-After when appropriate without leaking sensitive detection logic.
Observe and tune
Adjust thresholds using false-positive and abuse outcome data.
What to limit (and how)
Authentication flows
Login, OTP, and password reset need tight per-account and per-source budgets.
Expensive operations
Exports, searches, and AI/report jobs should be limited by cost units, not only count.
Data-rich reads
Pagination and listing APIs need ceilings to reduce scraping.
Write/actions
Comments, invites, and purchases need velocity rules tied to business risk.
Algorithms and dimensions
| Topic | Guidance |
|---|---|
| Fixed window | Simple counters per interval; can burst at window edges |
| Sliding window / token bucket | Smoother control of sustained and burst rates |
| Identity keys | Combine user, IP, token, and device—avoid IP-only dependence |
| Endpoint weight | Charge more quota for costly operations than for health checks |
Implementation checklist
- Apply limits on every client path: web, mobile, and partner APIs.
- Use multi-dimensional keys so distributed stuffing cannot trivially bypass controls.
- Return 429 consistently and avoid user-enumeration differences in auth errors.
- Pair limits with MFA, CAPTCHA/step-up, and anomaly detection for auth endpoints.
- Protect limit stores against bypass (enforce at gateway and application as needed).
- Monitor both blocked abuse and false positives affecting real customers.
- Document override processes for emergencies without permanently disabling protection.
- Test that horizontal scaling does not reset or desynchronize counters incorrectly.
The practical takeaway
Rate limiting caps how often identities may call sensitive or expensive operations. It is essential against guessing, stuffing, scraping, and resource exhaustion—and insufficient alone against clever distributed abuse.
Limit by meaningful identities and action cost, enforce everywhere the API is reachable, and tune with real traffic. Quotas buy time; authorization and business rules still have to be correct.
Related security terms
Brute-Force Attack
A primary abuse class rate limits are designed to slow.
Credential Stuffing
Distributed login abuse that requires multi-dimensional rate controls.
API Abuse
Broader misuse of APIs where rate limits are one defensive layer.
CAPTCHA
Friction often combined with rate limits when risk rises.
Rate Limit
Vulnerability-focused guidance on missing or bypassable rate controls.
Frequently asked questions
What is rate limiting in simple terms?
Rate limiting caps how often someone can call an endpoint. After too many tries, the service slows or blocks further requests for a while.
What HTTP status code is used?
Many APIs return 429 Too Many Requests, sometimes with Retry-After guidance. Some apps also use challenges or temporary lockouts.
Is IP-based rate limiting enough?
No. Attackers distribute traffic across many IPs. Effective limits also key on account, token, device, and action cost.
Can rate limiting stop all bots?
It raises cost and reduces naive floods, but determined adversaries adapt. Combine with bot management, authn, and business logic checks.
What should be rate limited?
Authentication, password reset, OTP verification, expensive searches/exports, and any high-value or high-cost API.
What is a token bucket?
A common algorithm that grants tokens over time; each request spends tokens, and requests are rejected when the bucket is empty.
How do you avoid harming legitimate users?
Use fair multi-key limits, progressive friction, clear errors, and higher ceilings for verified trusted clients while protecting sensitive actions tightly.
References
Explore authoritative guidance and frameworks related to rate limiting.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.