Warm reuse leaks

Why does a system that reuses its own leftovers to go faster start returning one user's data to another?

Reuse is the least controversial optimisation there is. Keep the connection pool open, keep the parsed config, keep the compiled template, keep the model in memory — the second request is fast because it inherits what the first one built.

And yet a recognisable class of serious incident begins exactly here: a user receives another user's dashboard, invoice, or profile. Not through an injection flaw or a broken permission check, but through a system that was being efficient. The question worth sitting with is why the same mechanism produces both the speed and the leak, because if they were separable somebody would have separated them.

Ask what "warm" means. A process, container, or isolate handled a request and was not destroyed, so whatever it wrote into memory is still there when the next request arrives. That persistence is the entire benefit — and it is unconditional: memory does not distinguish what you meant to keep from what you happened to leave.

So the safety of warm reuse rests on a classification. Some state is a property of the deployment — a connection pool, a parsed config, a compiled regular expression, model weights — identical for every request, so sharing it is right. Other state is a property of one request: the caller's identity, their tenant, the row they asked for. Sharing that is a data breach.

Now ask what enforces the classification. Nothing does. Both kinds live in the same memory with the same lifetime, and a module-scope variable holding a database client is indistinguishable to the runtime from one holding the current user. The boundary between "cache" and "leak" exists only in the developer's intent, and intent is not a mechanism.

Which is why the failure mode is so consistent in shape. Somebody writes request-scoped data into a location whose lifetime outlasts the request, and there are only a handful of such locations: a module-level variable used as a convenience handle; a shared client mutated per request rather than constructed per request, of which setting an auth token on a shared HTTP client is the classic; a cache keyed on something that omits the tenant, so two users' entries collide; a temporary file left on local disk, which many platforms preserve between invocations; a background task that outlives the response and finishes writing after the next request has started.

Notice the common structure. In every case the value was correct when written. The defect is not a wrong value but a value with the wrong lifetime — and lifetimes are invisible in most code, which is why this survives review: the line that assigns looks fine, the line that reads looks fine, and no single line is wrong.

Then there is the reason it survives testing, which is the more dangerous half. A cold instance has no leftovers, so the first request always behaves correctly, and a test suite that starts fresh exercises precisely the case that cannot fail. The bug needs two requests, from different principals, on the same warm instance, in that order — common in production, nearly absent from a test environment. This is path dependence in a strict sense: the output depends on the history of the process, and that history is not part of any input you thought to vary. The concurrency variant is worse again, since on a runtime handling overlapping requests in one process, request B can read what request A wrote a microsecond ago, in a timing-dependent window that is close to impossible to reproduce.

Is there a principled fix rather than a list of don'ts? It follows from the analysis: make lifetime explicit. Give each request its own container for its own state — a context object passed down the call chain, or the runtime's request-scoped storage — and make anything shared immutable after construction. Immutability is the load-bearing part: a value that cannot be written during a request cannot carry anything out of it, which converts an ambient risk into a structural guarantee. Where a cache genuinely must hold per-user data, put the principal in the key.

Three refinements.

First, the answer is not "stop reusing." Rebuilding a connection pool per request would be catastrophic for latency and for the database; the shared-state design is correct. What must change is that shared state be immutable after construction, and per-request state get a per-request home.

Second, the danger is not confined to two users of your own application. On a multi-tenant platform, leftovers can cross a trust boundary through the platform's own reuse, which is why isolation technologies assume one tenant's memory must never be visible to another's — and why the processor side-channel vulnerabilities of recent years were treated so seriously, since they attacked that assumption from below.

Third, an honest limit on tooling: static analysis catches some of this — a mutable module-level variable written inside a handler is detectable — but it cannot generally tell a legitimate cross-request cache from an accidental one, because the distinction is semantic. Load tests with distinct authenticated principals catch more in practice than any linter.

• How request-scoped storage is implemented on runtimes with overlapping requests, and what it costs.
• How to construct a load test that would actually fail on a cross-request leak, using distinct authenticated principals.

Every term the collection defines is gathered in the glossary.