Classify the response, enforce authentication and the intended cache policy at every managed layer, then verify account separation with synthetic data before purging and reopening the route.
A fast account page is only useful if it belongs to the person viewing it. When a website shows a previous visitor’s name, order or download entitlement, clearing a browser cache may conceal the symptom without repairing the boundary that failed. The important question is whether any stored response can be reused for the wrong request.
Investigate with synthetic accounts and harmless test records. This guide explains response policies and a repeatable account-separation check; it does not claim that a header certifies a website as secure. Authentication, authorisation and storage policy each need their own evidence.
Classify the response rather than the page label
List what the server actually sends for the route. An account dashboard can return public HTML followed by a personalised JSON request. Conversely, an apparently ordinary article can include a signed-in name inside its initial HTML. Record the document and background requests that carry the information, including redirects and error responses.
Use three practical classes: identical public content; personalised content that the user’s browser may retain under an agreed policy; and sensitive content that should not be stored in HTTP caches. This is a design decision for the application owner, based on the data and recovery requirements. Do not assume every URL containing “account” has the same needs.
A fictional membership site, for example, could cache its public help article while excluding the account JSON that reveals a member’s purchases. Test both requests. Removing caching from the article cannot repair a separately cached purchase response.
Separate a private cache from a shared one
MDN distinguishes private and shared caches. A browser cache normally serves one client; a shared cache can serve responses to multiple users. Reverse proxies and CDNs are common managed caching layers. A response suitable for one user’s browser may therefore be unsuitable for an edge cache.
A cookie on the request does not, on its own, declare the response private. The caching layer needs an effective policy. Check whether a “cache everything” rule, page-cache extension or custom worker applies to a route that changes with a session. The name of the hosting plan does not establish the answer.
Draw a short route map: browser, edge, hosting proxy, application and any additional response store. Assign an owner to each managed layer. This prevents a fix in the application being contradicted by an explicit edge rule you have not inspected.
Choose directives for the actual requirement
The Cache-Control reference gives these directives different meanings. Avoid treating their names as interchangeable “turn cache off” switches.
| Directive | Relevant meaning | What it does not establish |
|---|---|---|
| private | Shared caches must not store the response; private storage can remain possible. | That the response belongs to the authenticated user. |
| no-cache | Storage is permitted, but reuse requires successful validation. | A ban on retaining the response. |
| no-store | The response must not be newly stored by HTTP caches following that policy. | Removal of copies already stored elsewhere. |
For an invented dashboard whose browser may retain a response but must validate it before reuse, the application might choose the following policy. It is an illustration of intent, not a universal prescription for every account screen.
Cache-Control: private, no-cacheA more sensitive response may require no-store instead. Have the responsible developer apply the policy through the framework or server mechanism that owns the response. Verify successful responses, authentication failures and redirects, rather than assuming a setting on the happy path covers them all.
Inspect overrides and cache keys
Managed caches can implement product-specific rules, as MDN’s caching guide explains. Inspect those rules as well as the public headers. A response that displays no-store is not proof that an explicitly configured application store or managed rule cannot retain a copy. Ask the operator how storage eligibility and bypass decisions are actually made.
Vary describes request fields involved in response selection. It is useful for legitimate variants, such as a negotiated language, but it is not an authorisation check. Adding Vary: Cookie is not a substitute for declaring a personalised response private, nor does it fix a cache that ignores the relevant variation.
RFC 9111 also restricts shared reuse of responses to requests carrying Authorization, with defined exceptions. Cookie-based sessions are a separate case; do not assume the Authorization rules protect every login implementation. Check the actual request and the effective managed configuration.
Build a controlled two-account test
Create two authorised test accounts with obviously different synthetic records, such as “Example account A” and “Example account B.” Use separate browser profiles or isolated sessions, plus a signed-out session. A second tab sharing the same cookies is not an independent user.
- Request the route as A and record the harmless account marker, status and response headers.
- Request the exact same route as B; confirm B’s marker and inspect each personalised background response.
- Repeat while signed out; verify the intended access-denied or login result, with no A or B data.
- Reverse the order, beginning with B, to avoid testing only one possible warmed response.
- Repeat after logout and a fresh navigation, including relevant download and error paths.
Keep method, URL and query parameters comparable. If a test changes the URL to add a random cache-busting value, it may avoid the very collision you need to investigate. Use a separate diagnostic request only when you document what its changed cache key can and cannot prove.
Compare the body and headers together
Record Cache-Control, Vary, Date and any documented cache-status field. Age can help explain a stored response’s age, but a missing Age header is not proof that no caching occurred. Pair headers with the actual synthetic marker and the operator’s cache event or rule evidence.
For the fictional site, seeing A’s marker in B’s response is a failed boundary regardless of whether a dashboard says “cache miss.” Seeing the correct marker once is encouraging but does not cover every edge location, error path or session transition. Keep the acceptance claim limited to the tested routes and states.
Before sharing a diagnostic record, remove session cookies, authorization values, signed download URLs and real personal information. A sanitized test marker provides useful evidence without turning the incident note into another disclosure.
Repair the policy before purging old copies
If a shared response crossed users, restrict the affected route while the responsible operator investigates. Correct the storage or bypass policy first, then remove the relevant stored entries through each managed cache’s supported procedure. Purging first can briefly hide the issue until the next request repopulates the same unsafe entry.
Returning no-store does not retroactively remove an old stored response. Distinguish edge purges, application page-cache removal and browser state. Browser history can also restore an earlier page view, so test the logout and Back-button journey separately rather than assuming every visible page came from a new network request.
Preserve the previous configuration for rollback, but do not restore a demonstrated cross-account leak simply to recover a speed score. If real data may have been disclosed, retain appropriate restricted evidence and follow the site’s incident process; the synthetic retest cannot determine past exposure.
Keep public caching and private access as separate checks
Confirm that public articles still load correctly after the scoped change, while account data remains correctly separated. Noindex, hidden links and CSS visibility do not provide access control. A private PDF also needs a real entitlement check, covered separately in our paid-file delivery guide.
Finish with a route-level record: classification, authentication owner, cache policy, managed exceptions, purge performed and the A/B/signed-out results. The useful outcome is a verified separation boundary with a repeatable regression check, not simply an empty cache on the administrator’s laptop.
Sources and verification
Editorial review 2026-10-14. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- MDN: HTTP cachingChecked Private versus shared caches, cookie limitations, managed caching and the fact that no-store does not remove old entries.
Limits: Managed products can apply their own documented rules; this guide cannot establish a particular site configuration. - MDN: Cache-ControlChecked Response directives private, no-cache, no-store and shared-cache freshness controls.
Limits: Header syntax alone does not prove that an application or managed cache enforces the intended policy. - RFC 9111: HTTP CachingChecked Standards rules for storing and reusing responses, Authorization restrictions and cache validation.
Limits: Not a deployment-specific configuration recipe or an authentication mechanism. - MDN: VaryChecked How request-header variation contributes to cache matching.
Limits: Vary does not authenticate a request or replace a private response policy.