Home / Knowledge hub / Unrestricted resource consumption
Knowledge hub
Unrestricted resource consumption
API calls that can use unlimited CPU, memory, money or third-party credits.
What it means
Unrestricted resource consumption is an API flaw where a single caller can use more computing power, memory, bandwidth or paid services than is reasonable, because nothing sets a ceiling. It is entry four in the OWASP API Security Top 10 for 2023.
The resource is not always computing power. It may be SMS messages you pay for, emails sent, file storage, or calls to a third-party service billed per use. One request, or one script, can quietly spend a month's budget before anyone looks at the invoice.
Why it matters
The first effect is availability: an API slowed or knocked over by oversized requests or heavy queries. The second is money: cloud bills, messaging charges and third-party credits that rise with traffic you never intended to serve. A burst on a Friday night becomes a surprise on Monday morning.
Neither needs a skilled attacker. A customer's loop that forgot to stop, or a competitor scraping your catalogue, produces the same result, so intent does not matter to the outcome. It is a form of denial of service that can arrive through completely valid requests.
How it shows up
Look for parameters that scale work: page size, export size, nesting depth in GraphQL queries, file upload size, image dimensions, number of items in a batch, number of messages sent. Each needs a sensible maximum enforced on the server, not only in the front end.
Also check what happens at the edges: an expensive search with no timeout, a report that loads a whole table, endpoints that trigger SMS or email without a cap, and regular expressions that can be made to run for ages. Combine with rate limits, timeouts and spending alerts.
Questions people ask
Unrestricted resource consumption, answered
Is it the same as denial of service?
It overlaps, but is broader. Denial of service is about taking a system offline. Resource consumption also covers cost: no outage occurs, but you pay for something you never meant to give away.
Both come from the lack of limits.
Which limits should an API have?
Maximum request size, page size and batch size, execution time, memory use, number of calls per client, and caps on anything billable such as SMS or email sends.
Limits belong on the server and should return a clear error when exceeded.
How does it relate to rate limiting?
Rate limiting is one control within it: it caps the number of calls. But a single call can still be enormous, so you also need size, time and cost limits.
Use them together.
Can a feature like password reset be abused this way?
Yes. If each reset sends an email or SMS and nothing caps the number, an attacker can trigger thousands and run up your costs or flood a victim.
This is why messaging endpoints need strict per-account and per-target limits.
How do we test for it?
Send oversized values, ask for the largest page or export, nest queries deeply, and repeat costly calls in a burst. Watch response time, errors and, where you can, the bill.
Do it against a test environment with agreed limits.
Related
Terms that sit next to this one
API rate limiting
Capping how many calls a client can make so abuse and cost stay bounded.
Denial of service
Making an application unavailable by overwhelming or exhausting it.
ReDoS
A pattern match that takes enormous time on crafted input and freezes the app.
SMS pumping
Triggering paid text messages in bulk so you pay while the attacker is paid.
Pagination abuse
Asking for huge pages or walking every page to pull data out in bulk.
What does one request cost you?
We look for calls that do unbounded work or spend money, and report only what we actually exercised, with the request and response. Business-logic flaws like these are in scope. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.