An API endpoint returns data that differs per authenticated user. What has to be true before any shared cache such as a CDN or reverse proxy may store that response, and how do you design so one user's data can never be served to another?

## Private versus shared A **private cache** is dedicated to a single user: the browser's HTTP cache, an app's on-disk store. A **shared cache** stores responses for many users: a CDN edge, a reverse proxy in front of your service, a corporate forward proxy. The distinction is the whole safety question. A stale response in a private cache is a freshness bug; the same response in a shared cache can be a data breach. HTTP's built-in protection: a shared cache must not store a response to a request that included an `Authorization` header unless the response explicitly permits shared storage. That covers bearer-token APIs using the standard header — and nothing else. Cookie-based sessions, `X-Api-Key`, a token in a query parameter: none of them trigger that rule. The cache sees an ordinary GET, sees a response that looks storable, and stores it under a key that does not include the identity. The next user with the same URL gets the first user's data. This is one of the most common serious CDN misconfigurations in the wild. ## Designing so the leak is impossible, not merely forbidden **Separate the resources.** The most robust structure is to keep public data and personalized data on different endpoints. `/v1/products/42` is identical for everyone and can be cached hard at the edge; `/v1/me/recommendations` is per-user and is never given a shared-cache policy. A single endpoint that returns a public payload with a personalized fragment spliced in ("your price", "in your cart") forfeits all edge caching for the public 95% of the bytes. Composition on the client — fetch the cacheable resource plus a small personalized one — usually beats one personalized mega-response. **Make identity part of the cache key structurally.** A URL like `/v1/users/{userId}/orders` cannot collide across users, because the key differs. `/v1/orders` resolved from the token has one key for everybody, and its correctness depends entirely on nobody ever enabling caching for that route. Structural safety beats configuration safety, especially when the configuration lives in a different team's CDN console. **Label per-user responses private.** Say explicitly that only the requesting client may store the response. This is a belt-and-braces measure that also protects against intermediaries you did not know were in the path — corporate proxies, ISP caches on plaintext HTTP, buggy client libraries. **Understand what `Vary` can and cannot do.** `Vary` tells a cache which request headers form part of the key. In principle `Vary: Authorization` makes per-user entries safe. In practice it is a poor tool for personalization: every distinct token gets its own entry, so the hit rate collapses toward zero while storage explodes; `Vary: Cookie` is worse, because cookie strings carry analytics values that differ per browser, meaning near-total cache fragmentation and a false sense of safety if any path ever drops the header. Treat `Vary` as necessary for genuine content negotiation and as a warning sign when used for identity. **Default deny at the edge.** CDN configuration should cache nothing unless a route is explicitly opted in. The failure mode of the opposite default — blanket TTL with exceptions — is that any new endpoint is cached before anyone thinks about it, and the first personalized endpoint added after that leaks. ## Verifying it This is one of the few caching properties worth an automated test. Fetch a personalized endpoint as user A through the real edge, then as user B with a fresh connection, and assert the payloads differ and the response indicates a miss or a private policy. Also assert that no personalized route ever returns a header claiming shared cacheability. In incident review, the diagnostic signature is unmistakable: a burst of "I can see someone else's account" reports that correlates with cache hit ratio and disappears after a purge — by which time the wrong data has already been served. ## The judgement call Edge caching of authenticated responses is not forbidden — some high-scale systems do it deliberately by making the identity an explicit part of the cache key at the edge, and it works. But it is an opt-in engineering exercise with a proof obligation, not a default. For most APIs the right answer is: personalize as little as possible, keep the cacheable parts public and shared, keep everything user-specific private, and let the URL structure make a collision unrepresentable.