Caches must preserve privacy boundaries

A response’s correct audience must survive caching.

Who can reuse the copy?

A shared cache can reuse stored responses for multiple users. Its key selects a candidate response; HTTP rules and application policy determine whether storage and reuse are permitted. A correct identity check at the origin server does not automatically partition an intermediary’s cache.

Consider three unqualified response directives. private prohibits shared-cache storage while permitting a private cache, such as a browser cache, to store subject to other rules. no-cache permits storage but requires successful validation before reuse. no-store prohibits storage by caches. These are different requirements, not interchangeable spellings of “sensitive.”

Fictional profile policy

Assume a cookie-authenticated club portal has a personalized membership page.

• K1: The origin correctly returns each member’s own renewal date.
• K2: A proposed shared cache uses a path-only key. The design provides no exclusion for personalized responses.
• K3: Policy forbids storing this page in shared caches but permits storage in the member’s private browser cache.

Choose the boundary

Unqualified private matches K3. The review must also verify that the deployed shared cache honors that restriction. K1 is useful evidence about origin authorization, but it does not resolve K2. The record identifies an unreviewed design boundary, not an observed disclosure to another member.

Do not claim private encrypts content or makes a shared computer private. Browser account changes, local access, and retention still deserve their own policy. Changing a directive also does not prove that every previously stored copy disappeared; existing entries may need separate invalidation.

Decision: Specify the allowed storage audience, then verify actual cache behavior against it.