Overview
Rate limiting restricts how many requests a client can make in a period, protecting APIs from abuse — brute force, scraping, and resource exhaustion. This lesson covers rate limiting as an API security control.
Learning objectives
- Explain what rate limiting does and why APIs need it.
- Describe common rate-limiting approaches.
- Connect rate limiting to specific abuse it prevents.
Core concept
Rate limiting caps the number of requests a client (by API key, token, IP, or account) may make within a time window, rejecting or throttling excess requests (commonly with HTTP 429 Too Many Requests). It protects against:
- Brute force / credential stuffing — limiting login/authentication attempts.
- Scraping / mass data extraction — slowing bulk harvesting (e.g. iterating identifiers).
- Resource exhaustion / DoS — preventing a client from overwhelming the service.
Related controls include throttling and quotas over longer periods.
How it works
The API tracks request counts per client identity and time window; once the limit is exceeded, further requests are rejected (429) or delayed until the window resets. Choosing the right key matters — limiting per authenticated client/account is more meaningful than per-IP alone (which shared IPs and proxies complicate). Rate limiting is especially important on sensitive or expensive endpoints (authentication, search, data export) and complements object-level authorization: even where authorization is correct, limits blunt automated abuse like mass identifier iteration.
Practical example
A login endpoint enforces a limit of a few attempts per account/IP per minute; after that it returns 429, sharply slowing password-guessing. Separately, a data endpoint limits how many records a token can fetch per minute, hindering an attacker (or scraper) from rapidly iterating identifiers to harvest data. Without these limits, brute force and bulk extraction proceed unchecked; with them, automated abuse becomes impractically slow and detectable.
Cybersecurity relevance
Lack of rate limiting is a recognized API risk (unrestricted resource consumption / lack of anti-automation), enabling brute force, scraping, and denial of service. Rate limiting is a core defensive control, particularly on authentication and data-heavy endpoints, and it complements authorization and monitoring (429 bursts are also a detection signal). Testers check whether sensitive endpoints are rate-limited; defenders apply appropriate limits keyed on meaningful identities, with quotas for longer-term abuse.
Common mistakes
- No rate limiting on authentication endpoints, enabling brute force/credential stuffing.
- Limiting only by IP, which shared IPs/proxies and distributed attacks evade.
- Ignoring bulk-data endpoints, allowing scraping/mass extraction.
Key takeaways
- Rate limiting caps requests per client per time window (often returning 429), protecting against brute force, scraping, and resource exhaustion/DoS.
- Key limits on meaningful identities (account/token), not IP alone, and prioritize sensitive/expensive endpoints.
- Missing rate limiting is a recognized API risk; it complements authorization and monitoring and blunts automated abuse.
Check your understanding
- Name three types of abuse that rate limiting helps prevent.
- Why is limiting by authenticated client/account often more effective than limiting by IP address alone?