Rate Limiting and API Abuse: Throttling and Quotas

Most API abuse does not exploit a bug: it uses a legitimate endpoint far more often, far faster or far more widely than the designers expected. Credential stuffing, OTP guessing, scraping, SMS pumping, inventory hoarding and runaway AI inference costs all succeed against APIs that authenticate and authorise correctly but never ask "how much is too much?". This guide covers how to design rate limits, quotas and anti-automation controls that hold up against distributed attackers: where to enforce them, which keys to count on, how to respond, how to roll them out without breaking real users, and how to tell whether they are working. It is written for application security engineers, API platform owners and SRE teams. General API security is covered in the API Security Guide and volumetric attacks in the DDoS Protection Guide; this page focuses on abuse of individual functions and business flows.

Key takeaways

Limit by identity, not just by IP address. Distributed attackers rotate through thousands of addresses, so the counters that matter are per account, per API key or token, per target object and per business flow, with IP limits as a coarse outer layer.
Two OWASP API risks are about volume. API4:2023 Unrestricted Resource Consumption covers cost and capacity; API6:2023 Unrestricted Access to Sensitive Business Flows covers scalping, spam and fake sign-ups, which a single request per second limit does not stop.
Layer local and global enforcement. A coarse local limit at the edge absorbs bursts cheaply; a global, shared counter enforces the real policy across every gateway instance and region.
Write the limits down as requirements. OWASP ASVS 5.0 asks for documented per-user and global business logic limits (V2.1.3) and anti-automation controls (V2.4.1); limits invented at incident time are always too late.
Measure what gets through, not just what is blocked. The T-Mobile API incident ran for about six weeks before detection; per-client volume baselines and alerts on distributed low-and-slow patterns matter as much as the 429s.

What API abuse looks like

OWASP's Automated Threats to Web Applications project names 21 automated threats (OAT-001 to OAT-021). The ones that reach APIs most often, and the limit that actually constrains each, are below.

Abuse pattern	Reference	What is consumed	Control that constrains it
Credential stuffing and password spraying	OAT-008, ATT&CK T1110.004 and T1110.003	Accounts	Per-account and global failed-login limits, breached-password checks, MFA
OTP, PIN and reset-code guessing	OAT-002 Token Cracking	Short secrets	Per-code attempt cap, code expiry, ASVS V6.6.3
SMS or email pumping	API4:2023 scenario 1	Paid third-party sends	Per-recipient and per-destination-prefix quotas, provider spending caps
Scraping and enumeration	OAT-011 Scraping	Data records	Per-token object counts, pagination caps, object-level authorisation
Scalping and denial of inventory	OAT-005, OAT-021, API6:2023	Limited stock or slots	Per-flow limits, purchase caps, device and behaviour signals
Fake account creation	OAT-019 Account Creation	Sign-up and referral credit	Per-device and per-network sign-up limits, verification friction
Expensive query abuse	API4:2023, GraphQL batching	CPU, memory, downstream calls	Cost-based limits, query depth and complexity caps, timeouts
AI inference abuse and denial of wallet	OWASP LLM10:2025 Unbounded Consumption	Tokens and GPU time	Token-aware quotas per key and tenant, input size limits, budget alerts
Application-layer floods	ATT&CK T1499.003 Application Exhaustion Flood	Service capacity	Edge limits, autoscaling ceilings, load shedding

The table shows why a single "requests per second per IP" rule is not a strategy. Credential stuffing is about attempts per account and per credential source; SMS pumping is about money per destination; scraping is about records per token. Each needs its own counter.

Rate limiting algorithms and where to enforce them

Algorithms

Algorithm	How it works	Strengths	Weaknesses
Fixed window	Counts requests per calendar window (for example per minute)	Cheap, easy to explain	Allows a double burst at window boundaries
Sliding window log or counter	Counts requests over a rolling period	Smooth, no boundary burst	More memory or approximation
Token bucket	Tokens refill at a steady rate; each request spends one or more	Allows controlled bursts; can charge by cost	Burst size must be tuned
Leaky bucket or queue	Requests drain at a fixed rate	Protects fragile back ends	Adds latency; queue can fill
Concurrency limit	Caps in-flight requests per client	Bounds slow, expensive calls	Does not cap total volume
Quota	Allowance per day or month, often per plan	Commercial and cost control	Too slow to stop an active attack

Token buckets are the most common choice because a request can spend more than one token. That makes cost-based limiting possible: a GraphQL query, a bulk export or an LLM call charged by input and output tokens consumes allowance in proportion to the work it causes. See the GraphQL Security Guide for query cost analysis.

Enforcement points

Edge, CDN or WAF: cheapest place to drop floods and obvious bots before they reach application servers. AWS WAF rate-based rules, for example, count over evaluation windows of 60, 120, 300 or 600 seconds with a minimum limit of 10 requests, and can aggregate on IP, an IP taken from a forwarding header, or custom keys. See the Web Application Firewall Guide.
API gateway or service proxy: sees the authenticated client (API key, OAuth client ID, token subject), so it is the natural home for per-consumer limits and plan quotas. Envoy documents the common pattern: a local token bucket in each proxy for coarse first-stage limiting in front of a global rate limit service (a gRPC service, with a Go and Redis reference implementation) for fine-grained, shared counters.
Application: the only layer that understands business meaning, such as "five password reset requests per account per hour" or "two units per customer per product launch". Business flow limits belong here.
Downstream providers: spending caps and per-destination limits on SMS, email, payment and AI providers are the last line against cost abuse when everything upstream has failed.

Choosing the counting key

Key	Stops	Misses or harms
Source IP	Single-host floods, naive scripts	Residential proxy networks; penalises carrier NAT and corporate egress
IP prefix or ASN	Floods from one hosting network	Collateral damage to shared networks
Account or user ID	Brute force on one account, per-user abuse	Spraying one password across many accounts
API key, OAuth client or token	Abuse by a known integration or tenant	Attackers who mint many free keys
Target object (phone number, email, card BIN)	Pumping, enumeration, card testing	Needs application context
Device or session fingerprint	Distributed bots reusing one toolkit	Spoofable; privacy review needed
Global per endpoint	Distributed low-and-slow attacks no single key reveals	Can lock out everyone if used as a hard block

Use several keys at once and act on whichever trips first. A global counter on the login endpoint, for instance, is best used to raise friction (a challenge, step-up or slower responses) rather than to block, because a hard global block becomes a denial of service the attacker can trigger.

Authentication, MFA and passcode rate limiting

Authentication endpoints are where weak limits cause the most direct harm, and where standards are most specific.

NIST SP 800-63B (Revision 4), section 3.2.2: verifiers shall limit consecutive failed attempts on a single account to no more than 100, after which the authenticator is disabled and must be rebound. Lower limits are allowed. Permitted complements include a bot detection and mitigation challenge before an attempt, increasing waits as the account nears its limit (the example runs from 30 seconds up to an hour) and risk-based signals such as IP address, geolocation, timing and browser metadata. Rate limiting is required for passwords, look-up secrets and short OTP or out-of-band codes.
OWASP ASVS 5.0: V6.1.1 requires documentation of how rate limiting, anti-automation and adaptive response defend against credential stuffing and brute force; V6.3.1 requires those controls to be implemented as documented; V6.6.3 requires rate limiting on code-based out-of-band authentication; V6.6.4 requires rate limiting of push notifications to prevent push bombing.
Count per account and per credential source: per-account limits stop guessing on one account; spraying and stuffing need counters on failures per IP range, per device fingerprint and globally, plus breached-password screening. See the Password Spraying and Credential Stuffing Defence Guide.
Avoid lockout as the only response: hard lockouts let an attacker lock out users at will. Progressive delays, challenges and step-up authentication are usually safer.
Bind and expire codes: limit attempts per issued code (not just per account), invalidate the code after the cap, and limit how often new codes can be requested, which also limits SMS cost. See the MFA Fatigue and Bypass Guide.

The 23andMe credential stuffing breach shows the cost of missing these controls: stuffing ran for about five months, at one point exceeding a million login attempts in a day, before stolen data surfaced publicly.

Business flow, cost and AI limits

OWASP's guidance for API6:2023 splits mitigation into two layers: the business identifies which flows would harm it if used excessively, and engineering chooses the protection. That is a requirements activity, not a gateway setting. See the Security Requirements and Abuse Cases Guide.

Resource limits (API4:2023): OWASP lists the limits whose absence makes an API vulnerable: execution timeouts, maximum memory, file descriptors and processes, upload size, operations per request (such as GraphQL batching), records per page and third-party spending limits.
Business flow limits: purchases per customer per product, reservations per account, referral credits per device, posts per new account per hour. ASVS V2.1.3 asks for these to be documented per user and globally; V2.3.2 asks for them to be implemented; V2.4.2 (Level 3) asks for realistic human timing in business flows.
Webhook and callback limits: inbound webhooks need per-sender limits and signature checks before any expensive processing; outbound webhooks need per-destination concurrency limits and retry back-off so a failing customer endpoint does not exhaust your workers.
Token-aware AI limits: LLM endpoints should be limited by tokens and cost per key, user and tenant, not just requests, because one request can carry a full context window. OWASP LLM10:2025 lists rate limiting and user quotas, input size validation, timeouts and throttling, limits on queued actions and monitoring of resource use. See the Denial-of-Wallet and AI Agent Cost Runaway Guide and the AI Gateway and LLM Gateway Guide.

Responding to clients: 429, Retry-After and RateLimit headers

Mechanism	Source	Use
429 Too Many Requests	RFC 6585 section 4	The user has sent too many requests in a given amount of time. The response should explain the condition and may include Retry-After.
Retry-After	RFC 9110 section 10.2.3	An HTTP-date or a number of seconds to wait; also used with 503 Service Unavailable.
RateLimit-Policy and RateLimit	IETF draft-ietf-httpapi-ratelimit-headers (Internet-Draft, not yet an RFC)	Advertise the quota (q), window (w) and partition key (pk), and the remaining allowance (r) and reset (t).
Silent drop or connection close	RFC 6585 section 7.2	Under attack, sending a 429 for every request itself consumes resources; dropping connections may be more appropriate.

Two response styles serve different audiences. Honest 429s with Retry-After help legitimate integrations and SDKs back off correctly. Against attackers, the less you reveal the better: tarpitting, challenges, or returning the same generic failure whether a login was throttled or wrong all make tuning an attack harder. RFC 6585 deliberately leaves open how a server identifies the user and counts requests (per resource, per server or across a set of servers), so the policy design is yours.

Rate limit bypass techniques to design against

Spoofed client IP headers: if the application trusts a client-supplied X-Forwarded-For value, an attacker gets a new "IP" per request. ASVS V15.3.4 requires proxies and middleware to pass the original IP in fields the user cannot manipulate. Only take the address appended by your own trusted proxy.
Distributed sources: residential proxies and botnets spread requests below any per-IP threshold. Counter with per-account, per-object and global counters. See the Bot Management Guide.
Alternate paths to the same function: mobile API versions, legacy /v1 routes, GraphQL aliases and batch endpoints that reach the same logic without the same limit. Enforce limits on the function, not the URL.
Key and account farming: free tiers that issue unlimited API keys or trial accounts turn per-key limits into per-attacker unlimited. Limit key creation itself.
Case and encoding variants: /Login, trailing slashes or encoded paths that the WAF counts separately from the application route. Normalise before counting.
Race conditions: parallel requests that all pass the check before any counter increments. Use atomic increments in the shared store.
Inconsistent counters across regions: per-region limits multiply the allowance by the number of regions unless counters are shared or the limit is divided.

Implementing rate limits step by step

Inventory endpoints and flows: list every endpoint, its authentication, its cost (compute, third-party spend, data returned) and the business flow it belongs to. Start with login, registration, password reset, OTP verification, search, export and anything that sends SMS or calls an AI model.
Baseline real usage: collect 2 to 4 weeks of per-key, per-account and per-endpoint request rates. Set initial limits well above the 99th percentile of legitimate use so the first rollout blocks nothing real.
Write the policy as requirements: for each flow record the key, limit, window, burst, response and owner. Keep it in version control next to the gateway configuration.
Deploy in count or log-only mode: most WAFs and gateways support counting without blocking. Run for at least one full business cycle, including month-end or launch peaks, and review what would have been blocked.
Enforce in rings: start with anonymous traffic and high-risk flows, then authenticated consumers, then partners. Give partners notice and RateLimit headers before enforcement.
Add adaptive responses: challenges, step-up authentication and progressive delays for suspicious but not certain traffic; hard blocks only for clear abuse.
Test bypasses: include header spoofing, alternate routes, parallel requests and distributed sources in penetration tests. See the API Penetration Testing Guide.
Plan rollback: keep limits as configuration with a per-rule kill switch, so a misfiring rule can return to count mode in minutes without a deployment.

Decision guidance

Edge WAF rules or gateway limits: choose edge rules for anonymous floods and simple per-IP ceilings; choose gateway limits when the decision depends on who the client is or which plan they have. Most organisations need both.
Local or global counters: local counters are fast and cannot fail open on a shared store outage but are inaccurate across many instances. Global counters are accurate but add latency and a dependency. Use local for burst protection and global for policy, and decide in advance whether the global check fails open (availability first) or closed (abuse first) for each flow.
Static or adaptive limits: static limits are predictable and easy to audit. Adaptive or risk-based limits (sometimes sold as intelligent rate limiting) catch distributed abuse but need tuning and explainable decisions. Start static, add adaptive scoring to the highest-risk flows.
Small organisations: the managed rate limiting in a CDN, WAF or API gateway plus application limits on login, reset and OTP flows covers most risk. Provider spending caps are the cheapest control against cost abuse.
Large organisations: run a central rate limit service with shared policy, per-tenant quotas, and a review process for new endpoints, owned jointly by the API platform and application security teams.

Where identity fits

The most useful rate limit keys are identities: user accounts, API keys, OAuth clients and workload tokens. That only works if every machine consumer has its own credential. A single shared API key used by ten integrations makes per-consumer limits meaningless and hides which integration is misbehaving when the limit trips. Issue one key or client per integration, record an owner, and treat a sudden change in a machine identity's call volume or object access pattern as a security signal, not only a capacity issue. See the API Key Management Guide.

Detection and measurement

Log every throttle decision with the key that tripped, the rule, the endpoint and the client identity. ASVS V16.3.3 requires logging of attempts to bypass anti-automation controls. Useful detections include login failures spread across many accounts from one fingerprint, steady object enumeration just under the per-minute limit, and a machine identity whose daily volume jumps by an order of magnitude.

Coverage: percentage of internet-facing endpoints with an explicit, documented limit (target 100% for authentication, registration, reset and OTP flows).
False positive rate: throttled requests from legitimate users or partners, from support tickets and allow-list requests.
Time to detect bulk extraction: time from the start of anomalous per-client volume to an alert, tested with a purple team exercise.
Credential attack containment: successful logins per 1,000 failed attempts during stuffing events.
Cost per abuse event: third-party spend (SMS, AI tokens) attributable to blocked or undetected abuse each month.
Throttle rate by consumer: top consumers by 429s, reviewed weekly to tune limits and find broken integrations.

Framework mapping

Framework	Reference	Relevance
OWASP API Security Top 10 2023	API4:2023, API6:2023	Resource consumption and sensitive business flows
OWASP ASVS 5.0	V2.1.3, V2.4.1, V2.4.2, V6.1.1, V6.3.1, V6.6.3, V15.3.4, V16.3.3	Documented limits, anti-automation, authentication throttling, trusted client IP, logging
NIST SP 800-53 Rev. 5	AC-7, SC-5, SI-4	Unsuccessful logon attempts, denial-of-service protection, system monitoring
NIST CSF 2.0	PR.IR-04, DE.CM-01	Resource capacity for availability; monitoring of networks and services
MITRE ATT&CK	T1110.003, T1110.004, T1499.003	Password spraying, credential stuffing, application exhaustion flood
MITRE D3FEND	D3-ISVA, D3-RAPA	Inbound Session Volume Analysis, Resource Access Pattern Analysis
MITRE CAPEC	CAPEC-212, CAPEC-49	Functionality Misuse, Password Brute Forcing

Common failure patterns

Per-IP limits only: distributed stuffing stays under every threshold. The 23andMe breach involved more than 18,000 accounts accessed directly over months.
No volume baseline for machine clients: in the T-Mobile API breach, data on about 37 million accounts was pulled through one API from around 25 November 2022 until detection on 5 January 2023. T-Mobile has not said whether rate limits existed, but bulk retrieval at that scale went unnoticed for about six weeks.
Limiting the URL, not the function: the web login is throttled but the mobile API or a GraphQL batch reaches the same logic unthrottled.
Trusting client-supplied IP headers: every request appears to come from a new address and every per-IP counter resets.
No cap on paid side effects: SMS, voice and AI calls without per-destination limits or provider spending caps turn a script into a large bill within hours.
Hard global lockouts: a global block on login lets the attacker deny service to every user by tripping it deliberately.

Practitioner checklist

Inventory internet-facing endpoints and mark those with cost, data volume or business flow risk.
Document a limit, key, window and response for each high-risk flow, per user and globally.
Apply per-account, per-code and global limits to login, reset, OTP and push MFA flows.
Take the client IP only from your trusted proxy, never from a client-supplied header.
Combine edge, gateway and application limits, with a local burst layer in front of a global counter.
Limit AI endpoints by tokens and cost per key and tenant, and set provider spending caps.
Return 429 with Retry-After to known integrations; use challenges or silent friction for suspected attackers.
Roll out in count mode first, then enforce in rings with a per-rule rollback switch.
Log every throttle decision and alert on volume anomalies by machine identity.
Include rate limit bypass tests in every API penetration test.

Rate Limiting and API Abuse Guide: Throttling, Quotas and Bot Defence