Home / Knowledge hub / Rate limiting
Knowledge hub
Rate limiting
Capping how often something can be attempted, per user or per address.
What it means
Rate limiting caps how often an action can be attempted in a given period. Ten sign-in attempts an hour from one address, a hundred API calls a minute on one key, five password reset emails a day per account.
It does not decide whether an action is allowed. It decides how often. Those are separate controls, and this is the one that makes an attack expensive rather than impossible.
Why it matters
Most attacks on a sign-in page are attacks of volume. Working through a list of leaked passwords, guessing a six-digit code, counting up through customer ids to see which exist: each needs a great many cheap attempts. A limit turns an afternoon's work into years.
It catches accidents too. A partner's integration stuck in a retry loop takes a service down as effectively as anybody hostile, and so does a script somebody left running over a weekend. One control covers both.
How it shows up
The common mistake is limiting only the front door. The sign-in form is protected and the API behind it is not. You cap password resets per email address, so the attacker varies the address. A one-time code check has no limit at all, and six digits is a very short list. OWASP singles that case out, recommending a throttle on how often one client can run a single operation such as validating a code.
Three things are worth checking. Limits per account as well as per address. Limits on expensive operations such as report generation and file conversion. And a clear refusal using 429 with a retry hint, which RFC 6585 defines, rather than a silent failure that breaks honest clients.
Questions people ask
Rate limiting, answered
What limits should we set?
There is no universal number, and OWASP's guidance is to tune them per endpoint against how the business actually uses them. Authentication and one-time codes deserve much tighter limits than a search box.
Start from what a legitimate heavy user does in a busy hour, then leave headroom.
Can an attacker just change IP address?
Yes, and they do. Rotating through proxies or forging a forwarded-for header defeats a limit keyed only on the client address.
So count per account and per operation as well, because the attacker cannot rotate the account they are trying to break into.
Is rate limiting the same as blocking an attack?
No. It makes the attack slow and noisy rather than impossible, which is often enough to make it not worth doing.
It also gives you something to alert on, because a limit being hit repeatedly is a signal worth reading.
What should the response be?
RFC 6585 defines 429 Too Many Requests for this, and allows a Retry-After header saying how long to wait.
Returning a generic error instead means well-behaved clients cannot back off properly and will keep hammering you.
Will it break legitimate integrations?
It can, and usually because the limit was never documented. Publish the numbers, return the standard status code, and send the retry hint.
Then a partner's client backs off on its own instead of somebody filing a support ticket at midnight.
Related
Terms that sit next to this one
Brute force
Trying passwords or codes over and over until one of them works.
Credential stuffing
Trying passwords leaked elsewhere, because people reuse them.
Enumeration
Working out what exists by asking repeatedly and watching the answers.
Denial of service
Making an application unavailable by overwhelming or exhausting it.
API
The part of your application other software talks to, not a person.
How many tries do we get?
We test what your authentication paths accept and how often they accept it, and report each finding with the request and the response. We run no denial of service tests. Ask for a pilot.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.