Using Clear-Site-Data on Logout to Purge Client State

Q: Should I use the wildcard for logout?

Generally no. The wildcard includes executionContexts, so it can reload the user's other open tabs and tears down all Service Workers and Cache Storage. Use the explicit cookies and storage tokens for routine logout and reserve the wildcard for an account-compromise wipe.

This page is part of the Cache-Control and Clear-Site-Data reference and covers one job: emitting Clear-Site-Data on the logout response so the browser purges cookies, DOM storage, and cached entries the moment the session ends. Destroying the server-side session leaves all of that behind on the client; on a shared or kiosk device the next user inherits it. Clear-Site-Data closes that gap from the server.

Configuration Syntax & Exact Values

Clear-Site-Data: "cache", "cookies", "storage"

The value is a comma-separated list of quoted data types. The quotes are part of the wire syntax — an unquoted value is silently ignored.

Token	What it purges
`"cookies"`	Cookies and HTTP authentication credentials for the origin and its registrable domain. This is the primary token for session teardown.
`"storage"`	localStorage, sessionStorage, IndexedDB, Web SQL, Cache Storage, and Service Worker registrations for the origin.
`"cache"`	The browser’s HTTP cache entries for the origin, so a cached authenticated page cannot be re-rendered.
`"*"`	All defined types, including `"executionContexts"` — the browser may reload/navigate live contexts (other open tabs) of the origin. Use only for a full account wipe.

For a standard logout, the precise value is:

Clear-Site-Data: "cache", "cookies", "storage"

Use "*" only when you intend to also disrupt other open tabs and tear down Service Workers wholesale — for an account-compromise wipe, not a routine logout, because "executionContexts" will reload the user’s other tabs of your origin.

Server-Side Configuration

Set the header on the logout response specifically — the response to POST /logout (or the redirect that follows it). Pair it with server-side session destruction; the header is the client-side half, never the whole logout.

Nginx

location = /logout {
    add_header Clear-Site-Data "\"cache\", \"cookies\", \"storage\"" always;
    add_header Cache-Control "no-store" always;
}

The always flag emits the header even if the logout handler returns a redirect or an error, so cleanup is not skipped on a non-200. The inner quotes are escaped because Nginx uses double quotes to delimit the argument.

Apache

<Location "/logout">
    Header always set Clear-Site-Data "\"cache\", \"cookies\", \"storage\""
    Header always set Cache-Control "no-store"
</Location>

always appends the header on internally generated error documents too, which the default onsuccess table skips. Requires mod_headers.

Cloudflare

In Rules → Transform Rules → Modify Response Header, add a rule matching URI Path equals /logout, action Set static, header name Clear-Site-Data, value "cache", "cookies", "storage". Cloudflare emits this at the edge on the matched response. Add a Cache Rule bypass on /logout so the edge does not cache the logout response itself.

Node/Express (Helmet)

app.post('/logout', (req, res) => {
  req.session.destroy(() => {
    res.set('Clear-Site-Data', '"cache", "cookies", "storage"');
    res.set('Cache-Control', 'no-store');
    res.clearCookie('connect.sid');
    res.redirect('/');
  });
});

Helmet does not manage Clear-Site-Data; set it directly on the response. Destroy the session and clear the cookie server-side as well — the header is a defense-in-depth layer, not a replacement, because browser support is uneven. Behind a TLS-terminating proxy the response must reach the browser over HTTPS for the header to be honored.

The sequence a correct logout triggers in the browser is below.

The logout response carries Clear-Site-Data; the browser purges cookies, storage, and cache before following the redirect.

Diagnostic & Verification Steps

Confirm the header on the logout response:

curl -sI -X POST https://example.com/logout | grep -i clear-site-data
# clear-site-data: "cache", "cookies", "storage"

Browser DevTools: open DevTools → Application. Before logout, note non-empty Cookies, Local Storage, and Session Storage for the origin. Trigger logout. Open the logout request in the Network panel and confirm the Clear-Site-Data response header is present. Then re-inspect Application — Cookies, Local Storage, Session Storage, and IndexedDB for the origin must all be empty. Chromium logs Clear-Site-Data header found. Cleared data types: "cookies", "storage", "cache". to the console.

Expected behavior: after logout, pressing Back must not restore an authenticated view (pair with no-store on sensitive routes, covered in Cache-Control: no-store for sensitive pages), and re-requesting a protected route must redirect to login because the session cookie is gone.

Edge Cases, Security Implications & Safe Rollback

Only honored over HTTPS. The browser ignores Clear-Site-Data on a plaintext connection. Serve logout over HTTPS, enforced by HSTS. On HTTP the purge silently does not happen.
"*" also clears executionContexts. The wildcard reloads/navigates live contexts of the origin and tears down all Service Workers and Cache Storage. For a routine logout this can reload the user’s other open tabs and break an offline-capable PWA. Use the explicit "cookies", "storage" set unless you specifically want a total wipe.
SSO and cross-domain logout gaps. Clear-Site-Data is scoped to the response’s origin (and registrable domain for cookies). It does not purge state at your identity provider or at sibling apps on other domains. A federated logout must also hit the IdP’s logout endpoint and any other origins individually; one header on one origin does not end an SSO session everywhere.
Uneven browser support. Chromium and Firefox honor it; Safari support is partial and lags, and the "cache" type in particular has had inconsistent behavior. Always destroy the session and expire the cookie server-side so logout is correct even when the browser ignores the header.
Rollback. Purged data cannot be restored — there is no undo. “Rollback” means changing the header so the next logout purges less. If "*" is breaking a PWA, switch to "cookies", "storage"; if "storage" is wiping data users expect to keep across sessions, drop it to "cookies".

Frequently Asked Questions

Does Clear-Site-Data on logout end my SSO session everywhere? No. It only purges state for the origin that sent it. A federated logout must also call the identity provider’s logout endpoint and clear each participating origin; one header does not propagate across domains.

Should I use "*" for logout? Generally no. "*" includes "executionContexts", so it can reload the user’s other open tabs and tears down all Service Workers and Cache Storage. Use the explicit "cookies", "storage" (add "cache") for routine logout, and reserve "*" for an account-compromise wipe.

Is the header enough on its own? No. Browser support is uneven and the header is ignored over HTTP. Always destroy the server-side session and expire the session cookie as well; treat Clear-Site-Data as defense in depth.

Conclusion

Roll out incrementally: add Clear-Site-Data: "cookies", "storage" to the logout response in staging, confirm in DevTools that storage and cookies clear and that a protected route redirects to login afterward, then promote to production. Keep server-side session destruction in place as the authoritative mechanism and treat the header as the client-side cleanup that makes shared-device logout safe.