Clear-Site-Data: clear browser data deliberately

Three separate tasks during logout

An effective logout may involve three tasks: ending the server-side session or relevant tokens, removing browser-side credentials, and clearing remaining personal application data. Clear-Site-Data concerns the browser side. Deleting a cookie does not automatically invalidate a copied token that remains valid on the server. Conversely, Local Storage left behind does not make a correctly invalidated session valid again. Clear Site Data: use cases and limitations

The Web Security Check reads the header from the final response it retrieves. It does not perform a logout or observe deletion in the browser. The absence of the header on an ordinary content page may be entirely appropriate. Equally, ‘no session cookies detected in this response’ proves neither that a website has no login nor that application storage is absent.

Data left behind on a shared device

An account may be logged out while the application has previously stored profile information in Local Storage, IndexedDB or offline caches. Depending on the application, the next person using the same browser profile might still find that data. This is a possible data remnant, not an automatically restored session, and does not prove that every logout without this header is unsafe.

The scenario to test is: the application stores synthetic personal data → logout ends server access → browser clearing removes the intended data → the old tab, back navigation and another access attempt are checked. Active documents may still hold data in memory or write it again; a single clearing instruction is not a permanent access restriction.

Data types and scope

The values are strings enclosed in double quotes. Clear-Site-Data: storage is not a correct way to write Clear-Site-Data: "storage". Use the syntax from the specification, rather than arbitrary combinations of names.

Clear Site Data §§ 3–4 describes the mechanisms, but also contains unresolved specification questions and historical storage types. Operational use additionally depends on support for each data type.

The documented local Chromium test illustrates the scope: "cookies" also removed a cookie belonging to a neighbouring subdomain. "storage" removed the tested stores of the responding origin, while the neighbouring origin's Local Storage remained. A cookie set in the same response was also removed by "cookies". A notification cookie needed on the next page should therefore not be placed in the same clearing response without testing.

Assess support for each directive

The compatibility data read on 27 September 2026 lists basic support from Chrome 61, Firefox 63 and Safari 17. This does not mean that every value has the same effect:

• For Firefox, "cache" is documented from version 63 until before 94, and again from 138.
• Chromium has documented limitations for "cache" and "*", including responses reused in an existing tab and possible delays.
• "executionContexts" is not a reliable current feature across engines. The draft describes reinitialising active contexts; the compatibility data shows missing implementations or implementations that were later removed.
• Newer values such as "clientHints", "prefetchCache" and "prerenderCache" are not universal basic features. Do not infer support for them from support for "cookies" or "storage".

Public applications should serve the clearing response over HTTPS. Browsers require an appropriately trustworthy context; local loopback exceptions in a development test do not justify a public HTTP recipe.

A JavaScript fallback can only supplement this: it can clear known application stores selectively, but cannot, for example, remove HttpOnly cookies through document.cookie or empty every browser cache. Asynchronous IndexedDB, Cache and service worker operations must be awaited, with errors and open connections handled. A blanket localStorage.clear() can also remove data belonging to other features on the same origin. A universal ‘delete everything’ script would therefore be misleading.

Design a logout flow with limited deletion

First, the application defines what logout means: only this session, all sessions, an account switch, or the additional removal of offline content. Invalidate or revoke the relevant server-side permissions and tokens according to the actual session architecture. This does not require the same database operation in every system.

A response might then look like this, if clearing this origin's storage is intended and session cookies are correctly removed separately:

HTTP/1.1 303 See Other
Location: /abgemeldet/
Cache-Control: no-store
Clear-Site-Data: "storage"

For a flow deliberately intended to clear the wider cookie scope and network cache as well, Clear-Site-Data: "cache", "cookies", "storage" may be appropriate instead. This is a different decision with a greater loss of functionality, not an automatically better assessment. For password or account changes, decide separately how other sessions and local data should be handled.

A logout that changes state normally belongs in an appropriately protected POST flow. POST alone is not CSRF protection; the existing application must perform the necessary request checks. The browser must receive the actual response. A redirect is possible, but does not remove the need to send the headers on the correct response.

If logout is invoked through Fetch, check the credentials mode and network chain. In the documented local test, a same-origin clearing response worked with the normal credentials mode; with credentials: "omit", clearing did not occur. A response generated synthetically by a service worker with the same header did not work either, whereas a forwarded network response did. The draft deliberately restricts processing to network responses. Clear Site Data § 5.2

Judge success by the state that remains

Use synthetic data to check the following before and after the flow:

1. Server access using the previous session or old token is rejected to the intended extent of logout.
2. The intended cookies and stores have actually been removed; other applications on subdomains continue to function according to the deliberately chosen scope.
3. Old and new tabs, back/forward navigation, offline views and service workers do not show unwanted personal data. HTTP caching and bfcache are different mechanisms.
4. The flow also works in a target browser that does not support a desired directive. Logout must remain effective on the server.

For rollback, stop the clearing instruction at the responsible output point, restore any necessary sign-in and offline features, and check affected tabs. This does not reconstruct local data that has already been deleted.

Not evidence of complete data deletion

The header does not delete server data, backups, logs, files already exported or information outside its browser/origin scope. Complete removal of remnants on disk is not guaranteed either. The header alone therefore provides no evidence of GDPR, PCI or NIS2 compliance. Clear Site Data § 6.2, compliance overview