API4:2023 - Unrestricted Resource Consumption

Unrestricted Resource Consumption occurs when an API allows clients to trigger expensive operations without enforcing safe limits on request cost.

This is not only about high traffic. A single request can be enough to consume excessive CPU, memory, or backend capacity if the server blindly trusts attacker-controlled input.

This issue appears when client-controlled input directly determines how much work the backend performs.

Common examples include pagination limits, recursive expansions, bulk exports, large uploads, or expensive pattern generation.

Core Issue

# vulnerable
def search(term, limit):
    if limit < 1:
        raise HTTPException(status_code=400, detail="limit must be positive")

    expansion = [f"{term}-{i}-{term[::-1]}" for i in range(limit)]
    return {
        "count": len(expansion),
        "results_preview": expansion[:5],
    }

Correct Direction

# safer
MAX_LIMIT = 100

def search(term, limit):
    if limit < 1:
        raise HTTPException(status_code=400, detail="limit must be positive")

    safe_limit = min(limit, MAX_LIMIT)
    expansion = [f"{term}-{i}-{term[::-1]}" for i in range(safe_limit)]
    return {
        "count": len(expansion),
        "results_preview": expansion[:5],
    }

Key concept: the client may request work, but the server must decide how much work is acceptable.

From an attacker’s perspective, API4 is not only about sending many requests. It is about finding one parameter that makes each request much more expensive.

• Find parameters that control response size or processing depth
• Increase those values aggressively
• Probe for thresholds where behavior changes under stress
• Look for debug data or internal state exposed at high cost levels

If one crafted request consumes disproportionate resources, the API is already in dangerous territory.

A common example is a search endpoint that accepts an unbounded limit value and performs expensive expansion directly from user input.

Example endpoint:

Expected behavior: search size should be capped and stress conditions should never expose internal diagnostics.

Vulnerable Logic

expansion = [f"{term}-{i}-{term[::-1]}" for i in range(limit)]
data = {
    "count": len(expansion),
    "results_preview": expansion[:5],
}

if limit >= 10000:
    data["stress_debug"] = {
        "cache_state": "degraded",
        "flag": FLAG,
    }

• Unbounded Search: large limit or page values drive excessive response generation.
• Recursive Expansion: nested or deep expansion paths create disproportionately expensive processing.
• Large Upload Abuse: file size or parsing cost is not constrained safely.
• Stress-Induced Disclosure: internal debug fields appear only when the system enters degraded states.

1. Apply hard server-side limits

Search size, page size, expansion depth, upload size, and other cost-driving parameters must be capped by the server.

MAX_LIMIT = 100

safe_limit = min(limit, MAX_LIMIT)

2. Use execution guards

Timeouts, concurrency limits, and worker controls help prevent one request from monopolizing backend resources.

3. Treat public endpoints as high risk

Public or unauthenticated endpoints should not be assumed safe. They often provide the easiest attack surface for cost abuse.

4. Never expose stress or debug data

Internal diagnostics should not appear in client responses, even when the system is overloaded or degraded.

5. Monitor for disproportionate cost patterns

Track request parameters, execution time, and abnormal thresholds so expensive paths are visible before they become outages.

Detecting API4 requires testing how the backend behaves as request cost increases, not only whether the endpoint responds successfully.

Common techniques:

• Increase limit and pagination values aggressively
• Measure response time, size, and behavioral changes
• Find thresholds where the API becomes unstable
• Check whether high-cost requests reveal debug fields or internal state
• Test public endpoints as well as authenticated ones

Unrestricted Resource Consumption is not just a performance bug.

It exists whenever:

• The client can control request cost directly
• Server-side limits are missing or too weak
• Stress changes what the API returns
• Availability weakness turns into disclosure or instability

Every cost-sensitive endpoint should answer: Can a client force this API to do more work than the server safely allows?

If the answer is yes, the API is already exposed.