Home / Core Health / Add no-store cache headers to sensitive pages
Security Headers · Scan Check Guide

Add no-store cache headers to sensitive pages

20 min Impact: medium Effort: medium ✓ Scan-verified — no manual checkbox

Pages that show sensitive information — account details, order history, admin panels, search results with personal data — need a Cache-Control header telling browsers and shared caches (like a corporate proxy or CDN) not to store a copy, or the next person on that shared connection can see the previous user's page.

Login, account, and dashboard pages without Cache-Control: no-store can be saved by shared caches and browsers — meaning the next person on a shared or public computer might see the previous user's authenticated page.

The full picture

Cache-control headers with the no-store directive on sensitive pages prevent browsers and any intermediate caching systems from retaining copies of pages containing sensitive information — without this explicit instruction, sensitive content could remain accessible through browser cache or shared caching infrastructure even after a session ends or a visitor believes they've left the sensitive content behind.

This represents genuine risk particularly relevant to shared or public computer usage — a visitor using a public computer to access sensitive account information, then logging out and closing the browser, might reasonably assume that sensitive content is no longer accessible, but without proper cache control, a subsequent user of that same computer could potentially access cached copies of that sensitive content through browser history or cache.

The specific pages warranting this protection include anything displaying personal account information, financial details, or other genuinely sensitive content specific to an individual user — pages with this kind of content deserve explicit no-store instruction, distinct from general, non-sensitive content where caching provides legitimate performance benefits with no corresponding privacy risk.

Implementing this selectively, applying no-store specifically to genuinely sensitive pages while allowing normal, beneficial caching for non-sensitive content, balances the genuine privacy protection this header provides against the legitimate performance benefits caching offers for content that doesn't carry this same sensitivity concern.

How to fix it

  1. 1
    Identify pages that show account-specific or sensitive data
    Dashboards, account settings, checkout, admin areas, any page rendered differently per logged-in user.
  2. 2
    Add restrictive caching headers to those pages specifically
    Cache-Control: no-store, private on any page with sensitive or per-user content — this is different from your public marketing pages, which SHOULD cache normally for performance.
  3. 3
    Leave public, non-sensitive pages caching normally
    Don't apply no-store site-wide — that would hurt performance on pages that have no reason not to cache.

Common mistakes

How you'll know it's done

Pages with account-specific or sensitive content send Cache-Control: no-store, private; public pages continue caching normally.

H.I.V.E. checks this automatically

Fix it, then re-scan — the check confirms itself. No manual checkbox, the scan is the truth.

Run this check in H.I.V.E. →