Vary Is Not a Privacy Boundary for Authenticated Responses
Vary Is Not a Privacy Boundary for Authenticated Responses An HTTP cache can save bandwidth and reduce latency, but it also makes decisions about which request may reuse a stored response. The Vary response header tell
Vary Is Not a Privacy Boundary for Authenticated Responses
An HTTP cache can save bandwidth and reduce latency, but it also makes decisions about which request may reuse a stored response. The Vary response header tells caches which request header fields contributed to the response. RFC 9111 requires a cache to avoid reusing a stored response unless the nominated header fields match the original request, or the cache revalidates the response. That is a correctness rule for content negotiation. It is not a promise that a shared cache will protect private data.
A common mistake is to vary on Accept-Encoding or User-Agent while forgetting the cookie or authorization context that produced the body. If a response contains a personalized account panel and the cache key does not include the relevant identity, a second request can receive the first user's body. Adding Vary: Cookie can reduce the risk in some deployments, but it is a blunt instrument. Cookie values change frequently, can contain sensitive data, and may not be normalized consistently across cache nodes.
RFC 9111 also discusses responses to requests containing Authorization. A shared cache generally cannot reuse that response unless a response directive permits it and the reuse rules are satisfied. Teams should not depend on a proxy to infer privacy from an authentication header. Mark sensitive responses with Cache-Control: private or another policy that matches the data. Use no-store when retaining the response would create a recovery or device-storage problem, while recognizing that it may disable useful browser history behavior.
Cache-key design should be explicit. List the headers that affect the response, normalize their values, and test the exact variants that production will send. Decide whether the cache is browser-local, CDN-shared, or application-level. A CDN may have its own key configuration that ignores or rewrites an origin's Vary header. The security review should inspect both the origin response and the edge configuration.
A small test can expose a large problem. Create two accounts with different display names. Request the same URL through the proxy with each account. Confirm that the response body, status, and cache headers differ as expected. Repeat with the first request missing a cookie, a malformed cookie, and an expired session. Inspect the cache's hit or miss reason. If the edge reports a hit for a response that should be private, treat it as a data exposure until proven otherwise.
Content negotiation is not the only source of variants. Localization, feature flags, tenant routing, device class, and experiments can all change a response. Add a variation only after deciding what the response depends on and how the cache will isolate it. A custom header used for a private experiment should not become a global cache key unless every proxy understands it. A header that is absent in some requests can create a shared fallback that leaks the first variant.
For incident response, cache poisoning and cache leakage need different questions. Cache poisoning asks who could influence the stored response. Cache leakage asks who could read it. Both require the cache key and the response policy. Preserve proxy logs and the origin's Vary and Cache-Control headers. Do not clear a shared cache without first collecting evidence about which user or tenant received the response.
Vary is useful and necessary when the origin truly negotiates content. It is not a substitute for private caching rules. A safe design names the response's sensitivity, chooses a cache scope, creates a key that covers every relevant input, and verifies the behavior through the actual edge. The cache should be fast because the team knows what may be reused, not because nobody checked.
References
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.