What Is API Rate Limiting and Why Missing It Is a Security Vulnerability

What Is API Rate Limiting

Rate limiting is a control that restricts how many requests a client can make to an API within a defined time window. A login endpoint might permit five requests per minute per IP address. A search endpoint might permit 100 requests per minute per authenticated user. A password reset endpoint might permit three requests per hour per email address.

Without rate limiting, any endpoint is effectively open to unlimited requests — from any client, at any speed, without consequence. This creates a family of vulnerabilities that attackers actively exploit: brute force attacks on authentication endpoints, credential stuffing campaigns, data scraping, and resource exhaustion.

Missing rate limiting on APIs is documented in the OWASP API Security Top 10 as API4:2023 — Unrestricted Resource Consumption. It is one of the most consistently exploited vulnerabilities in web APIs because it is invisible to casual review — the endpoint works correctly, but its absence of constraints makes it dangerous at scale.

How Attackers Exploit Missing Rate Limiting

Brute force on login and authentication endpoints

A login endpoint that accepts a username and password with no rate limit can be attacked by submitting every password in a dictionary, one after another, as fast as the attacker's connection allows. A modern machine can attempt thousands of passwords per second against a rate-unlimited endpoint.

Against a single account with a common password, a brute force attack may succeed in seconds. Against a list of accounts with commonly reused passwords, it succeeds across a portion of accounts in proportion to how many use weak credentials.

Rate limiting alone does not prevent all brute force — a sufficiently patient attacker can spread attempts over time, and a sufficiently large botnet distributes attempts across many IP addresses — but it dramatically raises the cost and time required, making most brute force attempts impractical.

Credential stuffing

[Credential stuffing](/blog/what-is-credential-stuffing-attack) takes leaked username and password pairs from data breaches on other sites and automatically tries them against your API. Because many people reuse passwords across sites, a credential stuffing attack against an unlimited login endpoint will succeed against some percentage of accounts.

A rate-unlimited login endpoint can be hit by automated tooling at thousands of attempts per minute. Rate limiting combined with bot detection significantly reduces the success rate of credential stuffing.

OTP and verification code brute force

One-time passwords — six-digit codes sent by SMS or email for two-factor authentication or account verification — have a small space of possible values. An endpoint that validates OTP codes without rate limiting can be brute-forced in seconds. With ten attempts per second and a six-digit code space, the correct code is found on average in 50,000 attempts — a few hours without a rate limit, or nearly instant with a fast connection and no restriction.

This attack specifically undermines two-factor authentication when the OTP validation endpoint is not rate limited. An attacker with a stolen password can bypass 2FA by simply trying all possible codes.

Account enumeration at scale

A user lookup endpoint, a "forgot password" flow, or even a login endpoint with distinct error messages for "user not found" versus "wrong password" can be used for account enumeration — determining which email addresses or usernames have accounts. Without rate limiting, an attacker can enumerate millions of addresses in minutes, producing a confirmed list for targeted phishing or credential stuffing.

Data scraping

An API that returns structured data — product catalogues, user profiles, pricing, job listings — without rate limiting can be scraped entirely in a short time. A competitor, a malicious actor, or a data broker can extract the full dataset that your API makes available, removing the competitive advantage of your data and potentially exposing personal data of your users at scale.

Denial of service via resource exhaustion

Endpoints that trigger expensive operations — database queries, image processing, external API calls, PDF generation — can be used to exhaust server resources if they are not rate limited. An attacker (or a misconfigured client) that hits a resource-intensive endpoint repeatedly can degrade or bring down the service for all users.

How Rate Limiting Works

IP-based rate limiting

The simplest form: count requests per IP address within a time window. Allow up to N requests in the window, reject subsequent requests with HTTP 429 Too Many Requests until the window resets.

IP-based rate limiting is easy to implement and effective against unsophisticated attackers. Its limitations: it is bypassable by distributing requests across many IP addresses (a botnet or a list of proxies), and it can cause collateral damage if many legitimate users share a single IP (a corporate NAT, a university campus, mobile carrier NAT).

User-based rate limiting

For authenticated endpoints, rate limit by user identity rather than IP address. This prevents IP rotation from bypassing the limit, and avoids punishing legitimate users who happen to share an IP.

Endpoint-specific limits

Different endpoints have different risk profiles and different legitimate usage patterns. Apply strict limits to authentication, verification, and password reset endpoints. Apply more generous limits to read endpoints used by legitimate clients. Apply burst allowances where legitimate clients may make several rapid requests (pagination, bulk fetching) but overall volume should be constrained.

Progressive delays and CAPTCHA

Rather than a hard block, progressive delays — adding latency to responses after a threshold of requests, rather than rejecting them — can stop automated tools while preserving access for human users whose slower pace keeps them below the delay threshold.

Response headers

Return rate limit information in response headers so legitimate clients can self-throttle: `X-RateLimit-Limit`, `X-RateLimit-Remaining`, and `X-RateLimit-Reset` tell a well-behaved client how many requests remain and when the window resets.

What Yrzo AI Tests

Rate limiting testing requires sending repeated requests to endpoints and observing whether limiting is applied. A Yrzo AI scan specifically tests:

- Login and authentication endpoints for brute force resistance - Password reset and OTP validation endpoints - User lookup and account enumeration paths - Resource-intensive endpoints for abuse resistance

The [Professional scan (£399)](/checkout/standard) includes authenticated API testing that probes rate limiting on endpoints behind authentication. [Start with a free scan](/free) to check your unauthenticated endpoints.

Related reading: [What Is a Brute Force Attack?](/blog/what-is-a-brute-force-attack) · [What Is Credential Stuffing?](/blog/what-is-credential-stuffing-attack) · [How to Secure an API](/blog/how-to-secure-an-api-uk)