Without rate limiting, an API lets an attacker send unlimited automated requests. That can turn small weaknesses into major breaches through credential stuffing, data scraping and brute force. Rate limiting caps how often an action can occur. Validation proves whether an attacker could still abuse your API at scale.
What rate limiting is and why APIs need it
Rate limiting controls how many times someone can perform an action through an API within a set period.
For example, an API might allow only five login attempts per minute from a particular source. Without that limit, an attacker could send thousands or even millions of requests.
That difference matters because APIs are built for automation. Attackers can send requests much faster than a person can interact with a website.
A normal web page can slow an attacker down because it expects human interaction. An API does not need that interaction. It can process request after request unless a control stops it.
Rate limiting provides that control.
The goal is simple. Limit the number of requests an attacker can make before their activity becomes useful.
How attackers abuse APIs without rate limiting
When an API accepts unlimited requests, attackers can automate abuse at scale.
Common examples include:
- Credential stuffing: attackers test stolen usernames and passwords against a login endpoint until they find working credentials.
- Data scraping: attackers repeatedly request information from an endpoint and collect large amounts of data.
- Brute force: attackers test passwords, tokens or verification codes until they find the correct value.
- Enumeration: attackers send large numbers of requests to discover valid users, accounts or objects.
Each technique depends on volume.
An attacker may gain little from ten attempts. Give them a million attempts, however, and the situation changes.
Rate limiting makes that level of automation harder.
It does not remove every security weakness, but it can prevent attackers from turning a small weakness into a scalable attack.
Why unlimited requests amplify other weaknesses
The biggest problem with missing rate limits is not always the API itself.
The real problem is what an attacker can do with another weakness when they can repeat it at high speed.
Take a weak password policy.
A login endpoint might appear difficult to abuse if an attacker gets only a few attempts. Remove that limit and the attacker can test huge numbers of credentials.
The same principle applies to data access.
An API might return one customer record for each request. One request is not a major data breach. An attacker who can send millions of requests can turn that same endpoint into a large-scale data extraction tool.
Rate limiting therefore acts as a barrier against scale.
It keeps some attacks small enough to stop or investigate before they become serious.
That is why effective rate limiting should form part of api security testing rather than sit as an optional performance control.
Common rate limiting mistakes
Having rate limiting enabled does not automatically mean it works.
Attackers look for gaps.
One common mistake occurs when an organisation protects some endpoints but leaves others open. An attacker can simply move to the unprotected endpoint.
Another problem appears when limits apply only to IP addresses. Attackers can sometimes rotate IP addresses and continue sending requests.
Token-based limits can create similar gaps. If the application treats every token separately, an attacker may obtain or rotate tokens to bypass the intended restriction.
Limits can also sit too high.
A rule that allows 100,000 requests per minute may technically exist, but it might not stop a realistic automated attack.
Password reset and verification endpoints also deserve attention. Teams often protect the main login flow while leaving related authentication functions with weaker controls.
The pattern is consistent.
A rate limit only protects the paths it actually covers.
Validate that your limits hold under abuse
Configuration alone does not prove that rate limiting works.
A security console might show that a limit is enabled. That does not answer the more important question:
Could an attacker still abuse the API at scale?
Validation tests that question directly.
A controlled security testing for web application can simulate the type of automated behaviour an attacker would use. The goal is not to overwhelm the service. Instead, security teams can safely test request volumes, authentication flows and endpoint behaviour to confirm that the intended limits hold.
For example, testing can establish whether:
- Login attempts trigger the intended limit
- Password reset requests receive the same protection
- Verification codes have effective limits
- Different endpoints apply consistent controls
- IP rotation bypasses the limit
- Token rotation creates a new path around the control
- Limits respond before an attack reaches an unsafe scale
This produces stronger evidence than a configuration review.
The difference is important.
A configuration review answers:
“Is rate limiting configured?”
Validation answers:
“Can an attacker still abuse this API at scale?”
That is the question security teams need to answer.
Rate limiting needs continuous validation
APIs change constantly.
Developers add endpoints. Authentication flows change. Applications move between services. New APIs appear during product development. Existing controls can also change without the security team realising that a gap has opened.
A rate limit that worked six months ago may no longer cover the same attack paths today.
For that reason, testing the control once is not enough.
Continuous validation checks whether the control still works as the API changes.
Attack Insights takes this approach through API security and continuous service validation. The focus stays on proving what an attacker can actually do rather than assuming a security setting provides enough protection.
That distinction becomes increasingly important as organisations add more APIs.
Rate limiting is one layer of API security
Rate limiting matters, but it cannot fix every api vulnerability.
A weak authentication flow still needs a proper fix.
An endpoint that exposes too much information still needs to change.
An API that lets users access objects they should not see still has an authorisation problem.
Rate limiting simply limits how quickly an attacker can exploit some of those weaknesses.
Think of it as a barrier.
It can make automated abuse slower and harder. However, it should sit alongside strong authentication, proper authorisation and sensible data access controls.
Attackers will also look for the weakest path.
If the login endpoint has a strong limit but the password reset endpoint does not, the reset flow becomes the obvious target.
Security teams therefore need to validate the whole attack path rather than checking one control in isolation.
What effective API rate limiting looks like
Effective rate limiting starts with understanding how each API function can be abused.
First, map the endpoints.
Then identify the actions that attackers could automate. Login attempts, password resets, verification codes, searches, account lookups and data requests can all require different limits.
Next, test those controls from the attacker’s perspective.
The objective is not to find the setting that looks correct.
The objective is to prove that the control stops the behaviour it is supposed to stop.
Teams should also review how limits behave under different conditions.
Can an attacker switch IP addresses?
Can they rotate tokens?
Can they use different accounts?
Can they move to another endpoint?
Can they distribute requests across several paths?
These questions expose gaps that a simple configuration check can miss.
Prioritise exploitable abuse paths
Not every rate limiting gap deserves the same priority.
Security teams should consider what an attacker gains from bypassing the control.
A missing limit on a public search function may have a different impact from a missing limit on authentication.
A weak limit on a customer data endpoint may create a much more serious exposure than the same weakness on a low-value function.
Exploitability provides useful context.
Instead of counting every missing control equally, teams can ask which gaps an attacker could actually use and what they could achieve.
That approach helps security teams focus remediation on the paths that matter most.
Keep the control working after remediation
Fixing a rate limiting issue does not end the process.
The team should validate the change again.
Suppose developers add a limit to a login endpoint. A follow-up test can confirm that repeated requests now trigger the intended restriction.
The same api vulnerability testing should also consider related authentication paths.
If the attacker can simply move from login to password reset and continue the attack, the original fix did not close the full path.
Validation provides that feedback.
It confirms whether the change worked and highlights any remaining gaps.
This creates a simple cycle:
Discover → Assess → Validate → Remediate → Validate again.
That cycle helps security teams keep pace with changing APIs.
Stop automated abuse before it scales
APIs give attackers something they value: speed.
Without effective rate limiting, a small weakness can become a large-scale attack simply because the attacker can repeat it thousands or millions of times.
The answer is not to rely on a configuration setting.
Security teams need to validate that the control actually stops the behaviour an attacker would use.
That means testing authentication, data access, enumeration and other high-volume API actions. It also means checking the less obvious paths where attackers may bypass the main control.
Attack Insights helps security teams validate API exposure from the attacker’s perspective and confirm which weaknesses are genuinely exploitable.
To see how your APIs stand up to automated abuse, explore API security.
For a continuous approach to testing whether security controls still work as expected, see continuous service validation.
For the wider set of API risks, review the official OWASP API Security Top 10, including unrestricted resource consumption.
Request a Demo
Want to know whether attackers can abuse your APIs at scale?
Request a demo of Attack Insights to discover exposed APIs, validate exploitable weaknesses and prove that your security controls work against real attack behaviour.
Frequently Asked Questions
What is API rate limiting?
API rate limiting controls how many requests someone can make within a set period. It helps prevent automated abuse such as credential stuffing, brute force and data scraping. By limiting request volume, organisations can make it harder for attackers to repeat actions at a scale that could turn a small weakness into a major incident.
Why do APIs need rate limiting?
APIs support automation, which makes them useful for both legitimate applications and attackers. Without rate limiting, an attacker can send large numbers of requests very quickly. That speed can make credential stuffing, brute force, enumeration and data scraping much more effective.
What happens without rate limiting?
Without effective limits, attackers can repeat actions at high speed. They may test stolen credentials, guess passwords, enumerate accounts or collect large amounts of data. Rate limiting can restrict that volume and make these attacks harder to scale.
How do you know your rate limits work?
Validate them with controlled testing that mirrors realistic attacker behaviour. Test login, reset, verification and data endpoints, then confirm that the limits actually stop repeated requests. Test again after changes because new endpoints and authentication flows can create fresh gaps.
