Rate limiting sounds like a minor operational safeguard, but its absence has repeatedly turned into headline-grade breaches. In January 2023, T-Mobile disclosed that an attacker had used a single unmonitored API — with no meaningful throttling — to pull data on 37 million customer accounts over roughly six weeks before detection. In 2019, a security researcher showed that Instagram's password-reset flow could be brute-forced in about 10 minutes because the six-digit confirmation code endpoint accepted unlimited attempts. These aren't edge cases; they're the predictable result of shipping an API or login form without asking "what stops someone from calling this a million times?" Missing rate limiting is now formalized in the OWASP API Security Top 10 as API4:2023 — Unrestricted Resource Consumption — precisely because it keeps showing up in real incidents. This post breaks down why the gap persists, how attackers exploit it, and what actually closes it.
What Does "Missing Rate Limiting" Actually Mean?
Missing rate limiting means an API or login endpoint will accept and process requests at any volume or frequency a client sends, with no per-user, per-IP, or per-token cap enforced before the backend does real work. In practice this shows up as a REST endpoint that runs a full database query on every call with no throttle, or a /login route that lets the same username be tried against a password list indefinitely. OWASP catalogs this under API4:2023 (Unrestricted Resource Consumption) and it maps to CWE-770 (Allocation of Resources Without Limits or Throttling). The distinction that matters technically: authentication controls whether a request is allowed at all, while rate limiting controls how often an allowed (or even unauthenticated) request type can be repeated. Teams frequently harden the former and skip the latter, because a functional test suite never exercises "call this 50,000 times in a minute" — only a real attacker, or a load test, does.
How Have Real Breaches Been Caused By This Gap?
They've been caused by exactly this gap, repeatedly, across a decade of major incidents. T-Mobile's November 2022–January 2023 breach is the clearest recent case: a threat actor abused one API that had no rate limiting or anomaly detection, scraping name, billing address, email, phone number, date of birth, and account PIN data for 37 million current customers before T-Mobile noticed and shut it down on January 5, 2023 — its eighth reported breach since 2018. Optus, Australia's second-largest telecom, suffered a September 2022 breach affecting roughly 9.8 million customers after an internet-facing API endpoint required no authentication token and had no request throttling, letting an automated script enumerate customer records sequentially by ID. Panera Bread's 2018 incident followed the same pattern: a public API leaking millions of customer records could be scraped in bulk because nothing capped request volume, and the company reportedly sat on the report for eight months. In each case, the root technical failure making mass exfiltration possible — not just theoretically wrong, but feasible in hours — was the absence of a throttle.
Why Are Login Endpoints a Special Case?
Login endpoints are a special case because they convert missing rate limiting directly into account takeover, and attackers have automated tooling built for exactly this. Credential stuffing — replaying breached username/password pairs against other sites — depends entirely on being able to attempt logins at scale; Akamai's threat research has documented single campaigns generating billions of login attempts against media and retail targets in a matter of weeks. The math is unforgiving: a login endpoint with no lockout or throttling and a 6-digit OTP or reset code (1,000,000 combinations) can be exhausted in minutes at a few hundred requests per second, which is why Instagram's 2019 password-reset bug (found by researcher Laxman Muthiyah, who was paid a $30,000 bounty) was rated critical despite requiring no authentication bypass — just volume. Login forms are also uniquely attractive because a successful hit doesn't just leak data, it grants a persistent, reusable session or credential, so even a low success rate (0.1–2% is typical in credential-stuffing campaigns per industry telemetry) against a large enough attempt volume yields thousands of compromised accounts.
Where Does This Rank Against Other API Risks?
It ranks high enough that OWASP made it a named, standalone category rather than folding it into generic input validation. API4:2023 — Unrestricted Resource Consumption — sits in the current OWASP API Security Top 10 alongside broken object-level authorization (API1) and broken authentication (API2), and it explicitly covers rate limiting, request size limits, and resource exhaustion via unbounded array/pagination parameters. The category exists because APIs, unlike traditional web pages, are built to be called programmatically at speed — which is exactly what makes an unthrottled one so easy to abuse. Salt Security's State of API Security research has consistently found that a majority of surveyed organizations experienced an API security incident in the prior 12 months, and unrestricted resource consumption is one of the most cited root causes because it requires no clever payload — just a script and a for loop. Compounding the ranking: this class of flaw is invisible to traditional WAF signature matching, since each individual request is often perfectly well-formed; it's the aggregate pattern that's malicious.
How Can Teams Detect Missing Rate Limiting Before Attackers Do?
Teams detect it by actively probing volume-based abuse paths, not by reading code diffs, because the vulnerability is an absence rather than a flaw in existing logic. That means: enumerating every authentication, password-reset, OTP-verification, and data-export endpoint across an API surface (including shadow and undocumented APIs, which Salt Security and Gartner both flag as covering roughly 30% or more of a typical organization's live API footprint); sending controlled burst traffic against each to confirm a 429 or equivalent throttle response actually fires, and at what threshold; and checking whether limits are enforced per-IP only (trivially bypassed with rotating proxies or botnets) versus per-account or per-token, which is much harder to evade. This has to happen continuously, not once at launch — a new microservice, a refactored auth flow, or a partner integration can each silently reintroduce an unthrottled path. The gap between "we have rate limiting on our main login page" and "we have rate limiting on the 40 internal and partner-facing APIs that touch the same user database" is exactly where T-Mobile and Optus were breached.
How Safeguard Helps
Safeguard treats missing rate limiting as a first-class finding in software supply chain and application security posture, not an afterthought bolted onto generic pentesting. Our platform continuously discovers an organization's full API inventory — including shadow, deprecated, and partner-facing endpoints that rarely make it into an official API catalog — because you cannot rate-limit what security teams don't know exists. Against that inventory, Safeguard runs safe, automated probes that specifically test for API4:2023-class unrestricted resource consumption: verifying that authentication, password-reset, OTP, and bulk-data endpoints enforce real per-account and per-token throttling, not just per-IP limits that a distributed attacker sweeps around in minutes. Findings are prioritized by exploitability and business impact — an unthrottled login endpoint on a customer-facing identity service is flagged and escalated differently than a rate-limiting gap on an internal reporting tool — and mapped directly to OWASP API Security Top 10 and CWE-770 for audit and compliance evidence. Because API surfaces change with every deploy, Safeguard's monitoring runs continuously across CI/CD and production rather than as a point-in-time assessment, so a newly shipped microservice or a reintroduced auth path gets caught before it becomes the next T-Mobile-style disclosure. For security and engineering teams, that means moving from "we hope our WAF catches this" to a verified, evidenced answer to the question every one of these breaches exposed too late: does anything actually stop this endpoint from being called a million times?