When the cache forgot who a response belonged to

The login check worked

At the application, the account page behaved as expected. A signed-in client received information from a controlled account. An anonymous client was denied on the canonical route. The private response also carried a restrictive caching instruction.

Yet the same account body later reached a fresh client with no session. An intermediary had treated another representation as public and stored it. The application's privacy instruction had not survived the delivery path.

That explains why the successful login check wasn't the end of the investigation. The handler could refuse anonymous requests and private content could still escape through a layer in front of it. Both observations were true.

GET /redacted/observation HTTP/1.1
Host: research.example
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: private, no-store
Content-Length: 61

{"account":"[REDACTED]","content":"synthetic-private-marker"}

The disagreement sat between the handler and the client

The origin and the intermediary disagreed about what they were handling. One saw an account operation. The other applied a public caching classification, overriding the privacy instruction. Reviewing just the application code or just the cache configuration would miss the relationship between those decisions.

A shared cache can answer without running the handler at all. If it already holds private content as a public object, the login check may never get a chance to reject the request.

The repair therefore needs two separate checks: may this request use shared storage, and may this response enter it? Blocking new writes is not enough when old objects remain available. Lookup, storage, and route classification need to agree.

The same account body was the important evidence

A 200 response could be a public page or a sign-in screen. The useful evidence was the body: it matched private content from the controlled account and was delivered without a session. Together with the canonical route's denial, that supports an authentication-boundary disclosure.

It does not tell us how many accounts were affected, how long a cached object lived, or whether anyone accessed one before the research. Those require separate evidence. There is no basis here for claiming a historical breach or exposure across every private feature.

In a local regression suite, use independent client contexts and a harmless marker in a synthetic account. Compare that marker or a fingerprint of the fixture. The test doesn't need real account bodies or credentials in its output.

Make every cache layer respect the same rule

Start the proposed repair with a clear list of resources that are actually public. Use strict canonical routing and trusted route metadata shared with the intermediary. Private handlers bypass shared lookup and storage. If the classification is unknown or the layers disagree, bypass rather than guess.

The illustrative policy below checks before lookup and again before storage. The application owns the route registry and response classification; they are not claims accepted from the client. Each intermediary needs an equivalent rule.

# Synthetic policy for the repaired application.
lookup_policy(request, trusted_route):
    if not trusted_route.is_canonical:
        return BYPASS
    if request.has_authentication_context:
        return BYPASS
    if trusted_route.kind != PUBLIC_STATIC_RESOURCE:
        return BYPASS
    return ALLOW_PUBLIC_LOOKUP

storage_policy(lookup_decision, response):
    if lookup_decision != ALLOW_PUBLIC_LOOKUP:
        return DO_NOT_STORE
    if response.depends_on_identity:
        return DO_NOT_STORE
    if response.is_authentication_result:
        return DO_NOT_STORE
    if not response.explicitly_public:
        return DO_NOT_STORE
    return STORE_PUBLIC_RESOURCE

Then deal with what is already stored. Invalidate objects associated with private content and check the effective configuration, not just the header the application emits. Document how a routing change reaches each cache layer; otherwise, a later deployment can bring the disagreement back.

Check lookup and storage separately

Run these five local cases with in-process handlers, synthetic identities, and fake cache adapters. Assert which cache reads and writes happened, as well as what the caller received. No remote requests are needed.

The handler was only part of the answer

The application team and the infrastructure team need to be able to answer the same questions: what is public, what bypasses shared caching, and what happens to old objects when the policy changes? A header in the source code doesn't answer those questions for a deployed system. A verified repair would need evidence from that system; these notes do not establish one.

When a validation helper became a data query follows a different disagreement between layers: a small public form sitting in front of a much broader internal helper.