Caching Signed-In Pages: How to Keep One Account's Data Out of Another

Caching signed-in pages requires a response-by-response policy. Keep personalized responses out of shared caches, use no-store for sensitive responses, and allow browser storage only where the product can tolerate it. Then test with separate accounts through the real delivery path, including the CDN and any service worker.

A dashboard can load quickly and still return the wrong person's information. The useful question is which parts of the response another visitor could safely receive unchanged. That decision belongs in the application design and release checks.

1. Classify responses before choosing cache settings

Start with a small inventory of what a signed-in screen requests: its HTML document, account API responses, images, downloads and static application assets. A single page can combine public resources with private information. Giving every resource the same policy makes that distinction disappear.

MDN's HTTP caching guide distinguishes private caches, typically a browser cache, from shared caches such as proxies and CDNs. It explains that personalized content needs the private directive when storage should be limited to a private cache.

For planning, ask the product owner two questions about each response: could any visitor receive this exact content, and could the current user safely see an older copy? Record the answers beside the route or endpoint.

Use this table as a proposed review framework. The examples describe starting policies, not settings to apply without checking the actual response.

Classify the returned content, rather than relying on a route name. A public-looking homepage can become personalized when it includes an account summary.

2. Separate storage permission from freshness

Cache-Control answers more than one question. The private directive restricts shared-cache storage. It does not mean the browser must request a new response every time. A freshness policy still needs a deliberate decision.

The distinction between no-cache and no-store causes frequent mistakes. According to MDN's Cache-Control reference, no-cache permits storage but requires validation with the origin before reuse. No-store instructs HTTP caches not to store the response.

Choose between them based on whether retaining a response is acceptable. For example, a team might permit browser storage of a display preference but prohibit storage of a confidential account document. These are proposed product decisions, not universal classifications.

Write the requirement in ordinary language before implementation: "This response may remain in the browser, but must be checked before reuse" is easier to review than an unexplained header string.

Keep the technical scope clear. An HTTP cache policy does not replace authorization. The server must still decide whether the current requester can read the resource. A correct response header cannot repair an endpoint that returns another account's record.

3. Keep shared caching away from personalized content

For an account portal, a useful design is a reusable public shell that requests protected account data separately. This creates a boundary reviewers can inspect. The shell qualifies for shared caching only if its complete response is suitable for every visitor who can receive it.

Check server-rendered HTML carefully. A navigation bar, embedded initial state or account-specific link may personalize an otherwise generic document. Inspect response bodies as well as headers before allowing CDN caching.

Also review cache variation. MDN explains that Vary can distinguish representations using request headers, such as language. For cookie-based personalized content, its caching guide recommends private rather than using Cookie as the Vary value to prevent reuse by other users.

Ask whoever manages the CDN to document how route rules, cookies and application headers interact. Do not assume a setting observed at the origin survives every intermediary. Verify the response at the public hostname used by customers.

For a broader review of server protections, pair this work with the catalogue's web application security guidance. Cache isolation should have its own acceptance criteria even when authentication already passes testing.

4. Review service workers and browser-held application data

A header review covers only part of the system. OWASP's HTTP Headers Cheat Sheet recommends no-store for sensitive responses and warns that the Cache API does not honor HTTP caching headers. It calls for excluding sensitive responses from application-managed caches and removing existing sensitive entries.

If the application supports offline use, inspect which requests its service worker saves. Prefer an explicit list of approved public resources over a broad rule that stores every successful response. Treat protected endpoints and downloads as separate review items.

MDN's Cache API documentation also explains that application code manages updates and deletion. Entries do not automatically expire according to an HTTP freshness lifetime.

Review in-memory account data too. Propose a clear account-switching sequence: stop displaying the previous account's content, clear its retained application state, and fetch the new account's authorized data. Include delayed responses from the previous session in that test.

Browser history restoration is another separate behavior. A stored page snapshot is not equivalent to a new network request. Use the existing article on refreshing web app state after the Back button when defining that part of the experience.

5. Test account isolation through the deployed delivery path

Use test accounts containing obviously different fictional records. Avoid real customer data. Run the checks on a representative deployment with its normal CDN configuration, browser caching and service worker behavior enabled.

First, request a protected resource as account A to populate any eligible cache. Request the same URL as account B in a separate browser profile. Check the actual response body, not just the visible screen. Repeat in reverse order and as a signed-out visitor.

Then test sequential use in one browser: open account A, sign out, sign in as B, revisit the route and use browser history. This sequence examines retained browser and application state that separate profiles will not share.

Use this practical checklist as release evidence:

• List the document, API and download responses involved in one important account journey.
• Record each response's storage permission and freshness requirement.
• Inspect headers and bodies through the customer-facing hostname.
• Warm the delivery path as A, then request the same resources as B and signed out.
• Repeat account switching in one browser with normal cache settings enabled.
• Check service worker storage and application state after sign-out.
• Confirm public assets still cache as intended.
• Record the expected result, observed result and owner for each failure.

Keep browser developer tools from disabling the cache during these checks. Also test error responses and redirects reached during the journey. The acceptance criterion is specific: each requester receives only the content authorized for that requester, regardless of which account visited first.

6. Avoid common mistakes and choose a bounded next step

A short cache lifetime is not an account-isolation policy. Even a briefly reusable response needs the correct audience boundary. Likewise, seeing a cache miss once does not establish that later requests are safe.

Another mistake is fixing only future responses. Changing a header does not automatically remove copies already stored by intermediaries. MDN's Cache-Control reference notes that response directives cannot clear already-stored responses on intermediate servers. Include the affected layer's invalidation procedure in the remediation plan.

Avoid disabling caching across the entire site without classifying resources. Public assets and personalized responses have different requirements. Preserve useful caching where the content supports it, then investigate any performance cost of the protected paths separately.

Start with one account summary page. Assign a product owner to classify its responses and an engineer to trace their delivery and storage. Complete the two-account checks, resolve discrepancies, and retain the results with the route inventory. That produces a concrete policy the team can extend to other signed-in journeys.