The Textbook Definition of Rate Limiting
At its core, API rate limiting is straightforward: it controls how many times a user or client can access an API within a specific timeframe. If you exceed the limit, you get an error message telling you to slow down. Most organizations implement this
for two primary reasons: to ensure system stability by preventing any single user from hogging all the resources, and to protect against basic Denial-of-Service (DoS) attacks where an attacker tries to overwhelm the server with traffic. In a typical risk assessment, seeing that rate limits are in place often results in a checked box. The assumption is that the control is working, preventing the most obvious forms of abuse. But this is where the danger lies—in assuming all rate limits are created equal.
The Flaw: Who Are You Limiting?
The critical detail that changes everything is the identifier used for rate limiting. Many systems apply a general limit based on the originating IP address. For example, they might allow 100 requests per minute from any single IP. While this can stop a very basic attack from one computer, it's easily bypassed. Attackers can use botnets or proxy services to distribute their requests across thousands of different IPs, making the IP-based limit effectively useless. This is a common failure point because it treats all traffic as if it's coming from anonymous strangers. A proper risk assessment must ask a more precise question: are you limiting by IP address, or are you applying granular limits tied to a specific user account, API key, or session token?
Credential Stuffing: The Real-World Attack
This distinction becomes critical when defending against credential stuffing attacks. This is where attackers take lists of usernames and passwords stolen from other data breaches and systematically try them against your login API. If your rate limit is only based on IP address, an attacker can try one password for thousands of different user accounts from each IP, staying under the radar. A more secure approach is to implement a per-account limit. For instance, a rule that locks an account after five failed login attempts in 15 minutes is far more effective. Without this account-specific logic, your login endpoint becomes a validation service for criminals looking to see which of their stolen credentials work on your platform. Alarmingly, many organizations lack this granular control, leaving a massive gap in their defense.
Changing the Risk Calculation
This one detail completely changes a risk assessment. An assessment that previously concluded the risk of account takeover was "low" because "rate limiting is in place" is fundamentally flawed. The actual risk is high if that rate limit can't stop a distributed credential stuffing attack. The potential impact is no longer just a temporary service slowdown; it's a full-blown data breach. Attackers who successfully take over an account can access sensitive user data, make fraudulent transactions, and use that account as a launchpad for further attacks. Recent security reports have shown that a huge percentage of API attacks happen against authenticated sessions—meaning the attacker has already managed to get in. The failure to implement proper, granular rate limiting on authentication endpoints is often the first domino to fall.
