Unrestricted Resource Consumption

What Is Unrestricted Resource Consumption?

Some endpoints put no bound on how much work one request can demand. A list endpoint takes its page size straight from the request and passes it to the database with no server-side maximum, so a caller can ask for the entire table. You'll capture the caller-controlled limit parameter, rebuild the request asking for everything, and watch one response scrape the whole catalog while pinning the database. The fix clamps page size server-side and pairs it with cursor pagination. A re-probe returns a bounded 200 OK.

What You'll Learn in Unrestricted Resource Consumption

• Recognize unrestricted resource consumption where an endpoint places no bound on how much a single request can consume, so one call can force unlimited work
• Understand that a caller-supplied page size (or count, size, or depth) with no server-side maximum lets a single request return an entire dataset at once
• See that an uncapped page size is both a mass-scraping vector and a denial-of-service lever, because one oversized request exhausts memory and pins a database connection
• Distinguish this from object-level access flaws, over-serialization of fields, and authentication gaps; here authentication is fine and the missing control is a resource bound per request
• Apply the fix: clamp the requested page size to a server-side maximum, keep the cap on the server, paginate large result sets with a cursor, and add rate limiting per client and time window

Unrestricted Resource Consumption — Training Steps

1. A public browse feed

   Vendlo is a secondhand-marketplace app: members list things to sell, and anyone can browse the catalog. Today Bob is targeting Vendlo. He wants two things from it: the entire live catalog and its pricing, to resell to a competitor, and a cheap way to knock the API over if he decides to. He signed up as an ordinary member and opens the public browse feed to see how it loads.

2. Watch the request

   The grid Bob is looking at was drawn from data the app fetched over the API. It shows 24 listings and a note that there are far more behind them. Bob opens the browser network tools and reloads the page once to capture the call the app makes to build the feed.

3. The page size is the caller's

   The reload was captured, and the request is sitting in the Network panel. Bob reads how the app asked for its page of listings.

4. A quarter-million behind the page

   Bob opens the response the endpoint returned and reads what it says about the size of the catalog.

5. Ask for everything

   Bob rebuilds the same call in the API tester and changes one thing: instead of a page of 24, he asks for 250,000 listings in a single request. If the server honors it, one call will hand him the entire catalog.

6. One request, the whole catalog

   The server did exactly what it was asked. The response tells the story of what that cost.

7. The storefront buckles

   That one request is still running, grinding through a quarter-million rows and holding a database connection the whole time. Vendlo's connection pool is small, so while that query ties a connection up, the public storefront cannot get one of its own. Bob reloads Vendlo's page to see what a real shopper would see right now.

8. Real shoppers, locked out

   The same endpoint that just handed Bob the whole catalog now cannot serve an ordinary shopper. The API tester still shows his 200 with the full catalog; the storefront beside it shows what everyone else gets.

9. Knowledge check

   You just watched one request pull a quarter-million records and stall the database. Lock in why.

10. The alert lands

    You own Vendlo's catalog API. Overnight, monitoring flagged a single request that returned the entire catalog and held a database connection open for nine seconds, with API latency spiking across every endpoint while it ran. Security operations has emailed you.