A user clicks Log out, lands on the login page, then presses Back — and the dashboard reappears fully rendered with their name and data, restored from the back/forward cache. Why does the frozen page come back intact, and what are your options for handling state that has gone stale while a page sat in that cache?

## Why the stale page appears at all A restore is not a load. The browser reinstates a document it had frozen: the DOM as last rendered, the JavaScript heap with every variable and closure, framework component state, scroll position. No script re-runs, so nothing in the page has an opportunity to notice that the world moved on. Log-out happened on the *server* and in the *next* document; the frozen dashboard was never told and could not have listened if it had been. This generalises past auth. Anything the page rendered from data is a snapshot of the moment it was frozen: prices, inventory counts, unread badges, "3 minutes ago" labels, a shopping cart, a permissions-derived UI. The page can sit frozen for minutes before the user comes back. ## Lever one: refuse eligibility If a view must never be shown again after the user leaves it, make it bfcache-ineligible by serving the document with `Cache-Control: no-store`. Back then performs a real navigation, the server sees the request, and an invalidated session produces a redirect to login instead of a restored dashboard. This is exactly why authenticated pages have carried `no-store` for years. The cost is real and should be stated in an interview: you lose instant Back on that page permanently, for every user, including the overwhelming majority whose session is still perfectly valid. So scope it — apply `no-store` to the views that genuinely carry sensitive rendered content, not as a global default that quietly disables the feature site-wide. ## Lever two: keep eligibility, re-validate on restore The alternative is to accept the restore and immediately correct it. The restore signal is `pageshow` with `event.persisted === true`: ```js window.addEventListener('pageshow', async (event) => { if (!event.persisted) return; const res = await fetch('/api/session', { credentials: 'include' }); if (!res.ok) { location.replace('/login'); return; } refreshDashboardData(); }); ``` This keeps the instant-Back win for the common case and costs one cheap request in the restore path. Its weakness is a visible window: the stale content is painted before the check resolves, so for content that must never be *seen*, this is not sufficient on its own — you would need to hide or blank the sensitive region synchronously at the top of the handler before awaiting. The blunt version of the same lever is `location.reload()` inside the `persisted` branch. It is honest and simple, and it throws away the entire benefit of the cache for that page, so it is a reasonable fallback and a poor default. ## What else goes stale While frozen, the document runs nothing: timers do not fire, no `fetch` completes, no message is processed, no observer callback runs. Consequently, after a restore: - displayed clocks and relative times are wrong by however long the freeze lasted, - polled data is as old as the last poll before the freeze, - a WebSocket you left open may have been closed underneath you, and any messages sent meanwhile are gone, - another tab may have changed shared storage, and the frozen page did not process the `storage` event, - feature flags, permissions and prices may all have moved. The symmetric pattern handles most of it: in `pagehide`, stop polls and close connections, because a frozen page cannot stop them itself; in `pageshow` with `persisted`, restart them and re-pull whatever they feed. ## Choosing between the levers Ask what the failure actually costs. A stale unread badge is a cosmetic bug — re-validate on restore. A stale price on a checkout page is a commercial bug — re-validate, and block interaction until the check returns. A rendered view of someone's medical or financial data after logout is a disclosure — make the document `no-store` and take the reload. ## The framing interviewers want The weak answer is "bfcache is dangerous, turn it off". The strong answer separates two things: the cache is a large, free performance win on most pages, and *rendered state outliving its validity* is a property your application must reason about anyway — a phone left on a page for an hour, a restored tab, a duplicated tab all raise the same question. bfcache just makes it happen far more often, and gives you one precise hook (`pageshow` + `persisted`) to respond to it.