Resource Exhaustion Review

Resource Exhaustion Review

Correctness review asks whether the code produces the right answer. This asks what it costs to make it try. Availability is an invariant — bounded work per request — and it is the one invariant almost nobody writes down, so almost nobody notices when a refactor deletes it.

The measure that matters is not "is this slow?" but the asymmetry ratio:

What does one request cost the caller, and what does it cost the system?

A 40-byte request that allocates 4 GB has a ratio of 10⁸. That ratio is the finding. It does not require a botnet to matter — a single retrying client, a misconfigured integration, or a customer importing a genuinely large file will find it first, which is why this is reliability work as much as security work.

Scope: this skill reviews and hardens systems you own or are authorized to test. Load testing goes against your own environment with the owner's agreement. It produces limits, budgets, and load-shedding — never traffic aimed at anyone.

Composes with the library:

• validate-at-the-boundary — the limit belongs at the edge, with a clear error, before the value sizes anything
• secure-by-construction — bounds are part of the contract, written before the diff
• oracle-driven-fuzzing — a timeout or an allocation ceiling is an oracle; fuzz for the input that hits it
• concurrency-reasoning — retry storms, thundering herds, and pool starvation are concurrency failures wearing a capacity costume
• sql-aggregation-not-materialization — the database-specific case of loading unbounded rows into memory
• honest-degradation — when shedding load, fail visibly; never return a truncated answer as if it were complete

Part 1 — Follow the untrusted number

Grep-equivalent for this class: find every place an attacker-influenced value becomes a size, a count, a depth, or a repetition.

limit  count  size  length  depth  page  per_page  batch  n
range  repeat  timeout  retries  width  height  quality  scale

For each, ask three questions in order:

1. Is there a maximum? Not a default — a ceiling, enforced at the boundary, that a caller cannot exceed.
2. Is the work linear in it? Two nested loops over a caller-controlled list turn 10× input into 100× work.
3. Is the resource released? Bounded per request is not bounded in aggregate if a thousand requests each hold their bound simultaneously.

The classic sources of an untrusted number that reviewers miss: a length prefix in a binary format (allocating the declared size before reading it), a Content-Length used to preallocate, a JSON array's length, a page size, a recursion depth in nested structures, a count in a batch endpoint, image dimensions in a header, and a client-supplied timeout or retry count.

Part 2 — The amplification families

Two rules of thumb that catch most of it: never allocate what you have not yet received, and never let one request's work depend on a number the request itself chose.

Part 3 — Bound it at four levels

A single limit is usually the wrong fix; work down this ladder and take every rung that applies.

1. Bound the input. Maximum body size, maximum array length, maximum nesting depth, maximum decompressed bytes (stream and count, aborting when the ratio is exceeded — never decompress to memory to measure it), maximum page size with a hard server-side cap. Reject at the boundary with a clear error naming the limit.
2. Bound the work. A timeout and a memory ceiling per operation, enforced where the work happens. Replace the super-linear algorithm where one exists; for regex, prefer a real parser or a non-backtracking engine over patching the pattern.
3. Bound the concurrency. Bounded pools and bounded queues, so the system refuses rather than swallows. Apply backpressure: a full queue must reject, not grow. Retries need jitter, a budget, and a circuit breaker; retry at one layer only.
4. Bound the blast radius. Isolate expensive work in its own pool or worker so it cannot starve cheap requests. Quota per tenant, not only globally — one customer's import must not consume everyone's capacity. Shed load deliberately, and say so honestly in the response (honest-degradation), never by silently returning partial results.

Then write the bound down as a stated contract: "this endpoint accepts at most 1 MB / 1 000 items / depth 32, and completes within 5 s". Undocumented limits get removed by the next refactor; a limit in the contract gets a test.

Part 4 — Prove the bound, then keep it

• A limit without a test is a comment. Write the test that sends limit + 1 and asserts the rejection, and the test that sends the limit and asserts success. falsifiable-testing: see it fail first.
• Measure the ratio, do not estimate it. Run the worst case you can construct in your own environment and record input bytes → peak memory, CPU time, and downstream calls. That measurement is the evidence in the report; "could be exponential" is a hypothesis.
• Fuzz for it. Point oracle-driven-fuzzing at the parser with a timeout and an RSS ceiling as the oracle. This class is unusually well suited to automated search, because the oracle is trivial and needs no ground truth.
• Alert on the ratio, not just on the outcome. Requests whose cost exceeds the budget are a detection (detection-engineering) and an early warning that a limit was removed. Paging on the OOM is paging on the aftermath.

Deliverable

## Resource review — <component>
| path | untrusted number | ratio (in → cost) | current bound | proposed bound |

Measured worst case: <input> → <peak memory / CPU / downstream calls>
Bounds added: input / work / concurrency / blast radius
Tests: limit+1 rejected, limit accepted, measured under the ceiling
Stated contract: <the documented limits>
Not reviewed: <paths not covered>

Anti-patterns

• Treating this as a performance nicety and deferring it — availability is a security property, and the ratio is the finding.
• Adding a rate limit and calling the class closed: rate limits divide the cost, they do not bound one request's work.
• Setting a default instead of a ceiling, so a caller can pass a larger value.
• Decompressing fully in order to check the decompressed size.
• Retrying at every layer, multiplying load exactly when the system is degraded.
• Enforcing a global quota only, so one tenant can consume the whole budget.
• Patching a catastrophic regex by adding another quantifier.
• Shedding load by returning a truncated result that looks complete.
• Removing a limit during a refactor because "no test covered it" — which is the argument for the test, not for the removal.