Unrestricted Resource Consumption: The Bill and the Blackout

Every request an API serves costs something: CPU cycles, memory, disk, bandwidth, and increasingly a direct dollar amount for the third-party SMS, email, or cloud calls it triggers. Unrestricted Resource Consumption is the risk that an API places no meaningful limit on that spend — letting an attacker exhaust the system into a denial of service, or simply run the metered costs into the ground.

This category broadened the old "lack of resources and rate limiting" entry to include financial exhaustion, and that reframing matters. A modern API doesn't just spend its own compute; it spends your money every time it sends a verification text or invokes a paid model. An attacker who can call those flows in a loop turns your own infrastructure into the weapon.

The many ways to overspend

The obvious vector is volume: an endpoint with no rate limit, hammered until it falls over. But resource consumption is often about the cost per call, not the count. An endpoint that lets a client request ?limit=1000000 records, upload an unbounded file, or ask for a deeply nested query can be brought down by a handful of expensive requests that no request-per-second limit would catch.

• Volumetric. No rate or concurrency limit, so brute force and scraping run unchecked and legitimate traffic starves.
• Oversized payloads. Unbounded page sizes, request bodies, uploads, or response sizes let one call consume what should take thousands.
• Expensive operations. Complex searches, report generation, image processing, or deeply nested GraphQL queries that cost far more than an average request.
• Financial. Flows that trigger paid third-party calls — SMS, email, push, AI inference — with no cap, turning abuse into a bill.

Putting a ceiling on spend

Defence is about bounding every dimension of cost, not just requests per second. Limits should exist at the edge, in the application, and around the metered downstream calls.

• Rate-limit and set quotas per client. Cap requests per second and over longer windows, keyed to the authenticated caller or API key, with sensible burst handling.
• Bound every input and output. Enforce maximum page sizes, request body sizes, upload sizes, array lengths, and query depth — and reject anything over the limit rather than truncating silently.
• Constrain expensive operations. Apply timeouts, complexity limits, and pagination to costly queries; move heavy work to async jobs with their own quotas.
• Cap the wallet. Put hard spending limits and alerts on flows that call paid third parties, so abuse triggers a throttle and a page, not a five-figure invoice.
• Monitor for the spike. Alert on unusual consumption — a client suddenly pulling large pages or hitting a paid flow in a loop is often the first sign of abuse.

The trap in API4 is that the expensive endpoints are rarely the ones you watch. Rate limits get applied to login and forgotten on the report generator, the bulk export, or the new AI feature wired to a metered model. Every endpoint has a cost profile, and the ones without a ceiling are the ones an attacker will find — usually the endpoints nobody remembered were there.