Missing API Rate Limiting

How attackers find and exploit it

• Enumerate the target's API surface through passive recon: crawl JavaScript bundles, mobile-app traffic, public OpenAPI or Swagger documents, and DNS records to build a list of reachable endpoints such as /api/v1/login, /graphql, /password-reset, and /search.
• Probe routes and client identities for permissive behavior. A short burst without HTTP 429 or rate-limit headers does not establish that throttling is absent.
• Identify the highest-value unthrottled endpoint, prioritizing authentication and OTP/reset flows for account takeover, and search or pagination endpoints for scraping.
• Run credential stuffing or password spraying by replaying breached credential lists at high volume, often distributed across a proxy or residential botnet to defeat any per-IP heuristics, until valid sessions are obtained.
• Abuse expensive operations to exhaust resources or drive cost: send large or batched payloads (for example GraphQL query batching or deeply nested queries), request oversized pagination like ?limit=9999999, or loop SMS/email triggers to overwhelm CPU, memory, third-party quotas, or billing.
• Automate enumeration of objects and accounts by iterating identifiers or usernames to harvest data and confirm which accounts exist, using error and timing differences as oracles.

How to detect it on your surface

• Inventory every internet-reachable API endpoint, including undocumented, legacy, and versioned paths (v1, v2, internal/), since rate limiting is frequently applied to the primary login form but forgotten on a parallel mobile or partner endpoint.
• With authorization, run a bounded test matched to the route policy, client key, and time window. Record responses, delays, challenges, and dropped connections.
• Inspect rate-limit signaling headers as supporting evidence. Their absence does not prove that no limit is enforced.
• Test authentication controls within an approved safety bound. Compare failed attempts, delays, challenges, and lockout behavior with the configured per-account policy.
• Review API gateway, WAF, and load-balancer configuration to confirm a rate-limiting or throttling policy is actually bound to each route rather than merely available but unattached.

Detection signals

• For the same client key and policy window, traffic above the configured threshold continues normally without an equivalent delay, drop, or challenge.
• Responses omit rate-limit headers. This observation needs policy and behavior evidence before it becomes a finding.
• Login or reset flows permit more attempts than their configured per-account policy without lockout, backoff, or another effective challenge.
• Pagination, search, or GraphQL endpoints honor arbitrarily large or batched requests (for example very large limit/page-size values or multi-operation batched mutations) without rejection.
• Server-side latency, CPU, or errors rise under a bounded authorized test while the configured resource controls fail to engage.

Validate before you report

• Agree on an authorized test budget from the route policy, client key, and time window. Record the bounded request and response sequence. A fixed sample, such as 100 requests in 60 seconds, cannot prove absence when the threshold is unknown.
• Test through the public hostname and distinguish application responses from WAF or CDN controls, including delays, drops, and challenges.
• Test the relevant abuse path within the approved bound, such as repeated failed logins or costly operations. Compare observed behavior with its configured policy.
• Inspect deployed gateway, WAF, and application policy alongside observed behavior. If the policy cannot be verified, label the missing-limit claim unconfirmed.
• Record the endpoint, method, client key, time window, expected threshold, and observed enforcement. Do not infer absence from missing 429 responses or headers alone.

What looks like this but isn't

• A high threshold or alternate enforcement response is not an absent limit. Compare deployed policy with observed behavior; keep the finding unconfirmed if the policy is unavailable.
• Throttling may live upstream at a CDN, WAF, or API gateway rather than on the application, so a clean origin response does not prove the public-facing path is unprotected; test through the real internet-facing hostname.
• Authentication endpoints may enforce per-account lockout or CAPTCHA instead of per-IP rate limiting, which still mitigates credential stuffing; verify that no anti-automation control engages before concluding the endpoint is exposed.
• A non-production, sandbox, or intentionally public read-only endpoint may have rate limiting deliberately relaxed; confirm the endpoint serves real users or sensitive operations before assigning impact.

Remediation

• Enforce rate limiting on every internet-facing endpoint at the API gateway, reverse proxy, or framework layer, keying limits on the strongest available client identity (authenticated token or API key first, then IP) and returning HTTP 429 with a Retry-After header.
• Apply stricter, dedicated anti-automation limits to authentication, password-reset, OTP, and other sensitive endpoints, going beyond ordinary API throttling as OWASP recommends for these high-value flows.
• Add credential-stuffing defenses that do not rely on per-IP limits alone: enforce or step up multi-factor authentication, implement progressive delays and account lockout on repeated failures, and check submitted passwords against known-breached lists.
• Constrain resource cost per request by validating and capping payload size, pagination limits, query depth and complexity (for GraphQL), and the number of batched operations, addressing the resource-consumption side of OWASP API4:2023.
• Set hard spending caps on metered services where available. Where caps are unavailable, use billing alerts and a response plan; alerts warn of cost but do not bound it.
• Monitor and alert on 429 rates, per-client request volume, and authentication failure spikes, then feed this telemetry back into tuning thresholds and triggering graduated responses.

Operational checklist

• Maintain a living inventory of all public API endpoints and require that each new or changed route ships with an explicit, attached rate-limiting policy before release.
• Default-deny on rate limits: new endpoints inherit a sensible global throttle unless a route-specific policy is defined, so nothing reaches production unthrottled by omission.
• Hold authentication, reset, and OTP endpoints to a stricter standard with lockout/backoff plus MFA, and review these controls whenever the auth flow changes.
• Review deployed route policies and sample public paths with bounded authorized tests. Do not classify a limit as missing based only on absent 429 responses or headers.
• Review metered downstream services. Apply available hard spending caps, and assign an owner to respond to billing alerts where caps are unavailable.
• Track 429 volume, top talkers, and login-failure ratios on a dashboard and alert on anomalous spikes that indicate stuffing, scraping, or DoS in progress.

FAQs.

Weakness references (CWE)

• CWE-770 · Allocation of Resources Without Limits or Throttling
• CWE-799 · Improper Control of Interaction Frequency