Unrestricted Resource Consumption

How the Attack Works

Every API request consumes resources (network, CPU, memory, storage), and some trigger paid calls to third-party providers (e.g. sending SMS, biometric verification).

An API is vulnerable if at least one meaningful limit is missing or set incorrectly (too high/too low) - for example:

• Execution timeouts
• Maximum allocable memory
• Maximum number of file descriptors/processes
• Maximum upload file size
• Number of operations per request (e.g. GraphQL batching)
• Number of records per page
• Spending limits with third-party providers

The attack itself requires only simple API requests: the attacker sends many concurrent or massively repeated requests - from a single local machine or with the help of cloud resources.

The vulnerability is easy to find by manipulating parameters that control the amount of resources returned and analyzing response status, time, and length; the same applies to batch operations.

In the absence of limits, resource or cost consumption escalates unchecked.

Example

OWASP Scenario 1 (SMS-based "forgot password" flow): a social network sends a one-time token via SMS on password reset. When the user clicks "forgot password", the browser sends:

1. POST /initiate_forgot_password with the body { "step": 1, "user_number": "6501113434" }
2. In the background, the backend calls an SMS third-party provider: POST /sms/send_reset_pass_code to Host: willyo.net with the body { "phone_number": "6501113434" }
3. The provider Willyo charges 0.05 USD per call. An attacker writes a script that sends the first API call tens of thousands of times.
4. The backend follows every call and instructs Willyo to send tens of thousands of SMS messages - the company loses thousands of dollars within minutes.

Impact

Exploitation can lead to denial of service through resource exhaustion (the service becomes unavailable to legitimate users).

It can likewise drive up operating costs - for example through higher CPU load on the infrastructure or growing cloud storage needs.

Example from OWASP Scenario 3: a monthly cloud bill rises, in the absence of a cost limit/alert, from an average of 13 USD to 8,000 USD after a cached file grows from 15 GB to 18 GB and thereby falls out of the cache.

The business impact is application-specific (OWASP rating Business: Specific).

How to Protect Yourself

• Use a solution that makes it easier to limit memory, CPU, number of restarts, file descriptors, and processes - such as containers or serverless code (e.g. Lambdas).
• Define and enforce a maximum data size for all incoming parameters and payloads: maximum string length, maximum number of array elements, and maximum upload file size (whether stored locally or in the cloud).
• Introduce rate limiting: limit how often a client may interact with the API within a defined time period.
• Fine-tune rate limiting to actual business needs; individual endpoints may require stricter policies.
• Limit/throttle how often a single client/user may execute a single operation (e.g. validating an OTP or requesting a password reset without visiting the one-time URL).
• Add server-side validation for query string and request body parameters, especially the parameter that controls the number of returned records.
• Configure spending limits for all third-party/API integrations; where that isn't possible, set up billing alerts instead.

Sources

• API4:2023 Unrestricted Resource Consumption - OWASP API Security Top 10 OWASP, 2023