In a Denial of Service review, why does unauthenticated expensive work dominate the findings?

## The pattern Walk any design and mark, for every entry point, two numbers: what the **caller** spends to make the request, and what the **system** spends to serve it. Where the second is far larger than the first, and the request needs no identity, you have the highest-yield denial-of-service finding available at design time. It is the one worth writing first because it requires nothing of the attacker — no credentials, no privileged position, no flaw in the code. The feature working exactly as designed is the attack. The worked example: an upload path that generates a thumbnail before any authentication check. The request is a single POST of a small compressed file. The server decodes it into a raw pixel buffer whose size is width times height times bytes per pixel — a highly compressed image of a few megabytes can expand into gigabytes of resident memory. A handful of concurrent requests exhaust the heap; the process dies or the host starts swapping, and every other request on that instance dies with it. The cost ratio between the two sides is the whole finding. ## Why cost asymmetry, not request volume, is the metric Counting requests is the wrong lens. A design that can absorb ten thousand cheap requests per second may fall over on twenty expensive ones. During review, classify each operation by **input-driven cost** — cost that grows with something the caller controls: - Decompression and decoding (images, archives, video, documents) — output size is caller-chosen and unbounded relative to input. - Parsing that recurses or expands (deeply nested documents, entity expansion, huge collections). - Pattern matching whose runtime blows up on crafted input. - Deliberately slow cryptography — key derivation and password hashing are *designed* to be expensive. - Anything that fans out: one request that becomes many downstream calls, database rows scanned, or third-party API calls you are billed for. - Anything that holds a scarce handle for a long time: a connection, a lock, a worker thread, a temp file. Cloud spend belongs in this list. An unauthenticated endpoint that fans out to a metered third party denies service to your budget before it denies service to your users. ## The two independent fixes **Ordering.** Push cost behind checks, cheapest first. A defensible pipeline: terminate the connection with a size limit already applied; authenticate; authorise; validate declared metadata (content length, declared type, declared dimensions) and reject on mismatch; check the caller's quota; only then perform the expensive step. Each step earlier in the chain is cheaper than the one after it, so the further an attacker gets, the more they have had to prove. Ordering does not make the work cheap — it shrinks the population that can trigger it from *everyone* to *an authenticated principal you can name, throttle and revoke*. Be honest about where ordering cannot apply. Login is the standard counterexample: a password hash is expensive **by design** and must run before you know who the caller is. There the answer is bounding alone — keep the cost parameter at a defensible level, cap concurrent hashing with a bounded pool, reject immediately when that pool is full rather than queueing, and throttle per source and per targeted account so the rest of the API survives while the login path is under pressure. **Bounding.** Never trust declared metadata; enforce the real limit at the point of consumption. Cap decoded dimensions and total pixels, not just the byte length on the wire. Cap decompressed output and abort mid-stream when it is exceeded. Set a wall-clock timeout on the operation and on every downstream call it makes. Run it in a pool with a fixed size and a fast rejection path, so overload becomes a clean error rather than an out-of-memory kill. Where the work is not needed synchronously, accept, enqueue and return — the queue is where you apply per-tenant fairness and where you can shed load without dropping the interactive path. ## How to write the threat and the mitigation A useful entry names the element, the actor, the resource and the effect: *an anonymous internet caller posts a crafted image to the upload process, whose decode step allocates memory proportional to caller-chosen dimensions, exhausting the heap and denying uploads and all other traffic on that instance.* The mitigation then reads as an ordering claim plus a bound: *authenticate and check declared dimensions against a hard maximum before decoding; decode with an enforced pixel and memory cap inside a bounded worker pool with a timeout.* That pairing is what a reviewer is looking for. A candidate who answers only *add rate limiting* has bounded the count of requests, not the cost of any one of them — the single worst request still lands. ## Common wrong turns - Trusting `Content-Length` or a declared type as the size bound. The compressed size tells you nothing about the resident cost of the decoded form. - Treating it as a performance bug for later. Performance work targets the average request; this threat is about the worst request a stranger can choose. - Assuming autoscaling absorbs it. Autoscaling converts an availability problem into a bill, and scales too slowly against a burst anyway. - Adding a queue with no bound, so the memory pressure simply moves.