Unrestricted Resource Consumption (API Rate Limiting)
A Guide to Unrestricted Resource Consumption (API Rate Limiting)
Satisfying an API request consumes resources: network bandwidth, CPU, memory, storage, and sometimes paid third-party services like SMS or biometric validation. Unrestricted resource consumption occurs when an API fails to limit how much of that resource a single client interaction demands.
The risks posed by unrestricted resource consumption go well beyond a traditional denial-of-service concern. When an API integrates paid third-party services, a lack of spending limits turns resource consumption into a direct financial attack. A single automated script hitting an SMS-triggering endpoint generates thousands of dollars in charges within minutes.
GraphQL introduces a specific version of this risk: Its batching capability lets a client bundle hundreds of resource-intensive operations into one request, which sidesteps API rate limiting applied per individual request.
Key Takeaways
- Unrestricted resource consumption is ranked #4 in the OWASP API Security Top 10 2023 and occurs when APIs fail to enforce limits on client interactions, request sizes, or the computational resources required to fulfill requests
- The vulnerability extends beyond traditional DoS, missing spending limits on third-party API integrations (SMS, email, biometrics) can be exploited to generate significant financial damage, as shown in scenario #1 where an attacker triggered thousands of dollars in SMS charges in minutes
- GraphQL’s batching capability is a specific high-risk vector, allowing attackers to bundle hundreds of resource-intensive operations into a single request, bypassing per-request rate limiting entirely
- Resource limits must be defined at multiple levels: execution timeouts, memory allocation, file descriptor counts, upload file sizes, records per page, and number of operations per batched request, a gap at any one level creates exposure
- Prevention requires container-level resource constraints, fine-tuned rate limiting per endpoint based on business sensitivity, server-side parameter validation, and spending alerts or hard caps on all third-party service integrations
Why is it Dangerous
Left unaddressed, unrestricted resource consumption enables:
- Denial-of-service conditions that degrade or take down the API for legitimate users
- Direct financial loss through abuse of metered third-party integrations
- Resource exhaustion at the infrastructure level: memory, file descriptors, or process limits
- Bypass of rate limiting entirely through batched or bulk operations
Typical Manifestations
This vulnerability commonly appears when APIs:
- Impose no maximum on payload size, string length, or array element count
- Allow unlimited records per page in paginated responses
- Skip rate limiting on individual endpoints, particularly ones tied to costly operations
- Fail to throttle repeated calls to a single sensitive operation, such as OTP validation
- Have no spending cap on integrated third-party services
When an API assumes client requests will stay within reasonable bounds but does not enforce limits, the organization is open to attack.
Setting API Consumption Limits
Resource limits need to be enforced at every layer a request touches.
- Apply container-level constraints on memory, CPU, restarts, file descriptors, and process counts
- Define and enforce maximum payload sizes, string lengths, and array sizes on all incoming parameters
- Implement endpoint-specific rate limiting calibrated to business sensitivity, not a single blanket rule
- Throttle repeated execution of the same sensitive operation per client, such as OTP validation or password recovery
- Add server-side validation on any parameter that controls the number of records returned in a response
- Set hard spending caps or alerts on every metered third-party integration
APIs must enforce reasonable limits themselves rather than trusting clients to behave.
