In October 2023, OWASP published its refreshed API Security Top 10 and moved "Unrestricted Resource Consumption" into the fourth spot, replacing the narrower 2019 category "Lack of Resources & Rate Limiting." The change wasn't cosmetic. It reflected what security teams were actually seeing in production: attackers weren't just flooding login endpoints, they were sending a single GraphQL query that fanned out into 500,000 database lookups, uploading a 10KB file that decompressed into 10GB, or triggering a PDF-rendering job that pinned a container's CPU at 100% for twenty minutes. Every one of these is the same root flaw wearing a different costume — an API that never asks "how much is too much?" before doing the work a client requested. For companies shipping APIs built on third-party packages, CI/CD pipelines, and autoscaling cloud infrastructure, that missing question can turn into downtime, a five-figure cloud bill, or both.
What Is Unrestricted Resource Consumption in an API?
It's API4:2023 on the OWASP API Security Top 10, and it means an API accepts requests without any ceiling on the CPU, memory, disk, network bandwidth, or number of operations a single request can consume. OWASP's official description covers execution timeouts, maximum allocable memory, maximum file upload sizes, the number of operations a client can request in one API call (think GraphQL batching), and the number of records returned per page. Practically, it's the difference between an API that says "give me a page number and I'll return 20 rows" and one that says "give me any number and I'll return however many rows you ask for." The underlying weakness is catalogued as CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling) — both decades-old classifications that never went away, they just moved from desktop parsers into internet-facing APIs.
Why Did OWASP Broaden This Category in 2023?
Because rate limiting alone stopped being the whole story once GraphQL, file-processing endpoints, and pay-per-use cloud billing became standard. The 2019 API Top 10 framed this purely as "Lack of Resources & Rate Limiting" — essentially, throttle requests per minute and you're done. The 2023 revision, released in June of that year, expanded the category to cover resource type, not just request volume: a client can stay well under your rate limit and still exhaust you by requesting an enormous response payload, a deeply nested query, or a compute-heavy operation like image transcoding or regex matching. GitHub's own public GraphQL API is a good illustration of taking this seriously: it caps clients not by simple call count but by a points system (5,000 points per hour) and a hard node limit of 500,000 per query, precisely because a single cleverly nested query can be functionally equivalent to thousands of REST calls.
What Does an Attack Actually Look Like?
It looks like a technically valid request that is disproportionately expensive to fulfill. Four patterns account for most real-world cases. First, GraphQL query depth/complexity attacks, where a nested query (user { friends { friends { friends { posts { comments { author { friends... } } } } } } }) causes exponential backend work from one HTTP call. Second, decompression or "zip bomb" attacks, where a small uploaded archive expands to gigabytes in memory — the classic version of this goes back to CVE-2003-1564, the XML "billion laughs" entity-expansion bug in Expat, and the same principle still shows up in modern file-upload endpoints today. Third, regular expression denial of service (ReDoS), where a crafted input string makes a vulnerable regex take exponential time to evaluate; CVE-2022-3517 in the widely used minimatch npm package (CVSS 7.5) and CVE-2023-26136 in tough-cookie (CVSS 7.5) are recent, concrete examples that shipped in thousands of downstream projects before being patched. Fourth, unbounded pagination or batch endpoints, where a client requests limit=999999999 or submits a batch array with no cap on array length, forcing the database or worker pool to process far more than the UI ever intended.
Can This Actually Cost Money, Not Just Availability?
Yes — in cloud and serverless environments, unrestricted resource consumption converts directly into a billing event, a pattern researchers began calling "Denial of Wallet" as early as 2018. On AWS Lambda, Azure Functions, or GCP Cloud Functions, every invocation is metered and billed by duration and memory allocated; an API endpoint with no request cap and no per-client throttling lets an attacker (or a misbehaving integration partner) trigger thousands of concurrent, long-running invocations and hand you the invoice. The same dynamic applies to managed AI/LLM APIs: an endpoint that proxies calls to a model provider without a hard cap on tokens-per-request or requests-per-key can turn a single client into an unbounded line item on your usage-based bill. Public postmortems of five- and six-figure surprise cloud bills — most commonly triggered by exposed credentials or unthrottled functions looping on themselves — are common enough on engineering blogs and Hacker News that AWS itself publishes guidance on Lambda concurrency limits and billing alarms specifically to blunt this failure mode.
How Do Vulnerable Dependencies Turn This Into a Supply Chain Problem?
Because most resource-consumption flaws in production APIs don't originate in code your team wrote — they arrive through a package.json, requirements.txt, or Docker base image. The ReDoS bugs in minimatch and tough-cookie mentioned above weren't hand-written mistakes by the companies affected; they were inherited transitively, often several layers deep, through dependency trees most teams never audit line by line. An API endpoint that calls a validation library, a cookie parser, or a glob-matching utility inherits whatever resource-consumption ceiling (or lack of one) that library ships with. This is precisely why unrestricted resource consumption sits at the intersection of API security and software supply chain security: fixing it isn't only about adding rate limits at your gateway, it's about knowing which of your dependencies (and their dependencies) can be forced into pathological CPU or memory behavior by attacker-controlled input, and getting patched versions into production before a CVE is weaponized.
How Do You Detect and Fix This Before Attackers Find It?
You fix it by putting explicit, enforced limits on every axis a request can consume, and you detect it by testing those limits under adversarial input rather than assuming they exist. Concretely: set execution timeouts on every endpoint, cap request body and file upload sizes at the framework or gateway level, enforce maximum page sizes and reject unbounded limit parameters, apply GraphQL query cost analysis or maximum query depth (most modern GraphQL servers, including Apollo and graphql-java, support this natively), and set concurrency and payload caps on serverless functions rather than leaving them at cloud-provider defaults. On the supply chain side, that means continuously scanning dependency manifests and lockfiles against CVE and GHSA advisory data specifically for ReDoS and uncontrolled-resource-consumption classes (CWE-400/770), not just the more commonly triaged injection and auth bugs — because these findings routinely get deprioritized as "just a DoS" when the CVSS score and actual blast radius (cloud cost, cascading outage) say otherwise.
How Safeguard Helps
Safeguard is built to catch exactly this class of problem before it reaches a running API. Our software composition analysis continuously maps every dependency — direct and transitive — against live CVE and advisory feeds, flagging known uncontrolled-resource-consumption and ReDoS vulnerabilities like the minimatch and tough-cookie CVEs referenced above the moment they're disclosed, not weeks later during a quarterly scan. Because Safeguard tracks the full dependency graph rather than just top-level manifests, it surfaces the transitive packages most teams never manually review — the ones actually doing the regex matching or archive decompression behind an innocuous-looking API call. Findings are prioritized by real exploitability and reachability, so a vulnerable ReDoS function that's actually called from an internet-facing endpoint is triaged above one sitting in dead code. Combined with build and pipeline provenance checks, Safeguard gives engineering and AppSec teams a single place to see which APIs are one crafted request away from a resource-exhaustion incident, and to fix it as part of the normal CI/CD flow instead of after a bill or an outage forces the question.