What is rate limiting?
Rate limiting is a control that counts requests from each source over a period of time and refuses, delays or challenges the ones above a set threshold. The source can be an IP address, a user account, an API key, a session or a device. Many attacks are made of requests that look perfectly normal one at a time and become abusive only at volume: password guessing, credential stuffing, scraping a product catalog, enumerating usernames, hammering an expensive search page, or triggering thousands of password-reset text messages. A rate limit makes each of those slow or costly without getting in the way of ordinary users.
How rate limiting works
Most implementations keep a counter for each key and apply one of a few algorithms:
- Fixed window: allow, say, 100 requests per minute, resetting at the start of each minute. Simple, but a client can send a double burst across the boundary.
- Sliding window: count the most recent 60 seconds continuously, which closes that boundary gap.
- Token bucket: tokens refill at a steady rate and a client may spend saved tokens in a short burst, which suits real users who click several things at once.
A client over its limit usually receives 429 Too Many Requests, the HTTP status defined in RFC 6585, often with a Retry-After header saying when to try again. Stricter policies block the source for a period or present a CAPTCHA. Limits can be enforced in the application, an API gateway, a reverse proxy or load balancer, a WAF, a CDN, or a network firewall that caps new connections or SYN packets per second.
Example: protecting a login API
An API gateway in front of a mobile app's sign-in endpoint enforces three limits: 5 attempts per minute per account, 30 per minute per source IP address, and a ceiling for the endpoint as a whole. An attacker running a credential-stuffing list from one cloud server hits the per-IP limit within seconds and starts receiving HTTP/1.1 429 Too Many Requests with Retry-After: 60. When the attacker moves to a botnet and spreads attempts across thousands of addresses, the per-IP limit stops helping, but the per-account limit still caps guesses against any single user, and the endpoint ceiling raises an alert when total sign-in volume climbs far above normal. Layered keys matter because each one alone is easy to sidestep.
Setting limits without hurting real users
- Many people can share one address behind a corporate proxy, a campus network or carrier-grade NAT, so a tight per-IP limit can lock out an entire office.
- Base limits on measured normal traffic plus headroom, and log and alert before you start blocking.
- On login pages, prefer slowing or challenging over hard blocks, so an attacker cannot turn the limit into a way to lock out legitimate users.
- Give the same response whether or not an account exists, so the limit does not confirm valid usernames.
Rate limiting vs. account lockout and DDoS protection
Account lockout disables one account after a number of failed passwords. It stops guessing against that account but can be abused to lock out real users, and it does little against password spraying, which tries one password across many accounts. Rate limiting throttles the source of the requests instead. Neither one stops a volumetric DDoS that fills the internet link before traffic ever reaches the gateway; that takes upstream scrubbing from the ISP or a DDoS protection service.
Rate limiting on the CompTIA Security+ exam
Rate limiting is taught with firewalls among the mitigating controls in SY0-801 objective 4.1, and it shows up as a defense against the brute-force, credential and application-layer denial-of-service attacks covered under objective 2.5. Wording such as thousands of requests from a single client, an API being scraped or slow down automated login attempts without affecting other users points to rate limiting. Distractors include aggressive account lockout, which turns a password spray into a mass lockout; blocking the whole port, which takes the service offline; and a NIDS, which would alert but slow nothing down.