API Rate Limiting and Resource Consumption: What We Test For

An API with no limit on how much a single client can ask of it is a security gap, not a performance oversight. OWASP's API Security Top 10 names this Unrestricted Resource Consumption (API4:2023) precisely because it's common, easy to miss in a functional test, and genuinely damaging once found: an attacker who can make unlimited, unthrottled requests can degrade service for every other user, or quietly extract far more data than the endpoint was ever meant to expose in one call.

What "unrestricted" covers

This isn't only about raw request-per-second rate limiting, though that's part of it. It covers every dimension a client can push against without a defined ceiling: how many records a single paginated query can return, how large an uploaded file or payload can be, how deep a nested query can go, how many results a batch endpoint will process in one call, and how much compute a single request triggers server-side (image processing, PDF generation, and search/filter endpoints are frequent offenders). An endpoint can have a perfectly reasonable requests-per-minute limit and still be wide open to resource exhaustion through a single expensive request.

Where we find it in real testing

• Pagination parameters with no enforced maximum page size, letting one request pull an entire dataset
• File upload endpoints with no size cap, or no cap on concurrent uploads
• Search or filter endpoints that accept unbounded or deeply nested query structures
• Batch/bulk operation endpoints processing an arbitrary number of items per call
• Account-level actions (password reset requests, OTP sends, invite emails) with no per-account throttle, enabling abuse even when the API's general rate limit is fine

Why this matters beyond "denial of service"

Unrestricted resource consumption is often framed as purely an availability issue, but it has real data-exposure consequences too, an unbounded pagination limit is a legitimate way to bulk-extract an entire dataset through an endpoint that was only ever tested with small, reasonable page sizes. The business cost also isn't hypothetical: cloud infrastructure that scales with load means an attacker triggering expensive operations repeatedly can generate a real, unplanned bill, not just a performance dip.

What a real API assessment checks

• Every endpoint's actual enforced limits, request rate, payload size, pagination bounds, and query complexity, tested directly, not inferred from documentation
• Per-account and per-endpoint throttling specifically, since a global rate limit alone doesn't stop targeted abuse of one expensive endpoint
• Whether limits are enforced server-side, not just suggested in client-side code that a direct API call bypasses entirely
• Cost-amplification paths, the specific requests that trigger disproportionately expensive backend work

This is standard scope in our Web & API Security engagements, tested the same adversarial way as every other class of API vulnerability, not inferred from a spec, but actually exercised. For the broader authorization-focused vulnerability classes APIs commonly get wrong, see our piece on common API security mistakes.