Keep sensitive content out of history snapshots

HTMX 2 can store DOM snapshots in localStorage so Back and Forward restoration feels immediate. On a shared computer, that cache may outlive the visible page.

Imagine a task app that shows account email and API keys in the settings panel. Someone filters tasks, navigates to account settings, then clicks a link away. HTMX may snapshot that DOM into localStorage. The next person presses Back and sees the previous user’s email before the server redirect kicks in.

Prevent the current page state from entering that cache with:

<main hx-history="false">
  <!-- account or medical information -->
</main>

The attribute can appear anywhere in the current document or an inserted fragment. It embargoes the whole page snapshot, not only its own subtree. History navigation still works. HTMX requests the URL from the server when it must restore that state.

The server must authenticate and authorize the restoration request exactly like direct navigation. When Back triggers a fetch, DevTools shows GET /settings with HX-History-Restore-Request: true. That header is rendering context, not permission. An expired session should still return 401 or redirect to login.

Do not render API keys, raw tokens, unnecessary personal data, or secrets into HTML in the first place. hx-history="false" protects against one browser cache. It does not remove content from the DOM, screenshots, extensions, logs, or network responses.

Shared machines, support sessions, and kiosks are the main reason I reach for hx-history="false". The feature is convenient on a personal laptop. On a shared screen it can leave readable DOM in storage longer than the session badge suggests.

Test by navigating away, opening Application > Local Storage in DevTools, and pressing Back. Confirm no snapshot contains the sensitive markup. Then expire the session and confirm the server still denies restoration.