A no rate limiting vulnerability exists whenever an API endpoint accepts an unbounded number of requests from a single client without slowing, blocking, or challenging them, and it is one of the most common findings in real-world API assessments precisely because it is so easy to overlook. OWASP's API Security Top 10 calls this out directly as unrestricted resource consumption, and it shows up constantly in login endpoints, password reset flows, OTP verification, and search or export functions that quietly do expensive work per request.
This post covers what a no rate limit vulnerability actually enables, why it is so common even in otherwise well-built APIs, and the practical steps to detect and fix it.
What does a no rate limiting vulnerability owasp finding actually mean?
OWASP's API Security project has consistently flagged unrestricted resource consumption as a top-tier risk because rate limiting sits at the intersection of security and availability. An endpoint with no rate limiting will process requests as fast as a client can send them, which means an attacker's only constraint is their own infrastructure, not yours. That turns a login form into a brute-force target, a password-reset endpoint into an account-enumeration tool, and an expensive search or PDF-export endpoint into a denial-of-service vector, all without needing any other bug in the application.
The finding is distinct from, though related to, broken authentication. You can have perfectly correct password hashing and session handling and still be fully exposed to credential stuffing if the login endpoint accepts unlimited attempts per second from a single IP or account.
Where does missing rate limiting actually get exploited?
Authentication endpoints are the most common target. Login, password reset, multi-factor code verification, and account-recovery flows are all high-value because they gate access to an account, and a no rate limit vulnerability on any one of them lets an attacker try large volumes of stolen credentials from breach dumps in minutes.
Beyond auth, expensive read or compute endpoints get hit for denial-of-service purposes: an unthrottled search endpoint that hits a database with a wildcard query, an unthrottled PDF or CSV export that spins up a rendering job per request, or a webhook or notification endpoint that can be triggered repeatedly to spam downstream systems or third parties. API-first products are particularly exposed here because so much of the surface area is machine-callable by design, and rate limiting is one of the controls most likely to get deprioritized under a feature deadline.
Why does this vulnerability persist even in mature engineering teams?
Rate limiting is easy to skip because it does not block normal functional testing. A QA suite that makes a handful of requests per test run will never trip a rate limit that should exist, so the absence of one does not show up as a functional bug. It typically only surfaces in a dedicated security review or a DAST scan that specifically probes for it by hammering an endpoint.
It is also easy to implement inconsistently. A team might add rate limiting at the API gateway for the most obvious endpoints, login in particular, and forget it on newer endpoints added later, on internal-facing APIs assumed to be low risk, or on GraphQL resolvers where a single request can trigger many expensive nested queries that a flat per-request limit does not account for.
How do you detect and fix a missing rate limiting issue?
Detection starts with mapping every endpoint that performs authentication, sends a message or notification, or does non-trivial compute or I/O per request, then checking whether a request cap exists per IP, per account, or per API key. A DAST scan run against a staging environment is a practical way to verify this dynamically rather than relying on a code review to catch every path, since rate limiting is often implemented at infrastructure layers, like an API gateway or reverse proxy, that a source-code-only review will not see.
The fix itself has a few standard layers. Apply rate limits at the API gateway or edge for broad protection, then apply tighter, endpoint-specific limits for sensitive operations like login and password reset. Key the limit on more than just source IP, since IP-based limiting alone is trivially bypassed with rotating proxies; combine it with per-account and per-credential tracking where possible. Return a standard 429 Too Many Requests response with a Retry-After header so legitimate clients back off cleanly, and log rate-limit trips so a spike in triggered limits becomes a detectable signal rather than silent noise. For GraphQL and other query-based APIs, complement request-count limiting with query cost analysis, since a single request can otherwise hide an unbounded amount of backend work.
Teams evaluating scanning coverage for this category specifically should compare how thoroughly a tool exercises authentication and resource-heavy endpoints; see a breakdown on Safeguard vs. Snyk for how DAST coverage differs across vendors.
FAQ
Is rate limiting a security control or a reliability control?
Both. It protects availability against accidental traffic spikes and buggy clients, and it protects security against brute force, credential stuffing, and scraping. Most teams under-invest because they think of it only as the reliability half.
What is a reasonable rate limit for a login endpoint?
There is no universal number, but a common pattern is a low per-account threshold, for example 5 to 10 attempts before a short lockout or delay, combined with a broader per-IP limit to catch distributed attempts, plus alerting when either threshold is repeatedly hit.
Does an API gateway automatically provide rate limiting?
Most modern gateways support it, but it is usually opt-in per route, not on by default. Confirm it is actually configured for every sensitive endpoint rather than assuming gateway presence equals protection.
Can rate limiting alone stop credential stuffing?
No. It raises the cost significantly but should be paired with breached-password checks, multi-factor authentication, and anomaly detection for a complete defense, since a patient, low-and-slow attacker can still operate under a poorly tuned limit.