Clear-Site-Data is an HTTP response header that tells the browser to clear stored data for a site, such as cookies, cache or storage, depending on the directives used. Teams use it after logout, account recovery or compromise to remove residual state. It should be tested carefully because it can disrupt sessions and local data.
What Clear-Site-Data actually tells the browser to do
Clear-Site-Data is a server instruction carried in an HTTP response header. The browser reads the directives and clears the matching data types for the site that received the response, typically cookies, cache, storage, or execution-related state. The important point is that the server is not deleting data itself, it is asking the browser to remove specific client-side state.
The scope is origin-based, so it affects the site that sent the header and not arbitrary data across the browser. That makes it useful for ending a session cleanly, but also means the exact effect depends on which directives are present. If you tell the browser to clear broadly, you can remove more state than you expected and force a fresh login or reset local application behaviour.
Because the header is declarative, the browser decides how to apply it within the rules of its own storage model. In practice, that means you should think of it as a controlled client-side cleanup mechanism rather than a guaranteed secure erase operation. Sensitive workflows should still assume that some residual traces may exist elsewhere, such as in the user’s environment or external systems outside the browser.
Which data types are commonly cleared
The value of the header is a comma-separated set of directives, each targeting a broad category of browser state. Common uses include clearing cookies to end authentication state, cache to remove stored responses, and storage to remove local application data. Some implementations also use it to clear execution-related state so that a site starts again in a more neutral condition.
For practitioners, the practical question is not whether the browser supports the header in theory, but which state your application actually depends on. If your front end uses local storage for preferences, offline data, or session-related markers, a broad clear can change user experience in ways that are not obvious from the logout flow itself. A narrow directive set is often safer than a “clear everything” approach.
Security Headers Guide covers how Clear-Site-Data fits alongside other browser security headers, including cookie attributes, cache control and rollout considerations.
When teams use it and what can break
Teams usually send Clear-Site-Data after logout, account recovery, privilege reset, or suspected compromise. The goal is to remove residual browser state that could let a user continue using an old session or an attacker reuse cached application data. That makes it a strong control for cleaning up client-side trust state after an access event changes.
The trade-off is that the same cleanup can also disrupt legitimate user state. Users may lose active sessions, offline data, remembered preferences, or browser-resident application data that the product team assumed would survive. This is why it should be exercised deliberately in staging and checked against the exact browsers and storage types your users rely on.
NIST SP 800-88 Media Sanitization is a useful analogue for the cleanup mindset here, because it distinguishes between clearing data and more complete sanitization outcomes.
Risk and Threat Considerations
Clear-Site-Data reduces residual browser state, but it does not remove all compromise paths. If a session token, cached page, or local storage item has already been exposed, the header only helps after the response is delivered and only for the browser state it can reach.
Failure mechanism: An attacker with an already-open session, stolen token, or access to stored browser data can keep acting until the browser receives the clearing response, and any state outside the browser’s control remains untouched. Overly broad directives can also break legitimate recovery workflows and create avoidable availability issues for users.
Impact: The header is best treated as a containment and cleanup measure, not as a standalone compromise fix. Used correctly, it narrows residual access after logout or recovery; used carelessly, it can erase useful local state without fully eliminating the underlying exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-34 — Non-Modifiable Executable Programs | Browser state cleanup can affect cached or stored client-side execution state tied to site behavior. |
| Recommendation — Review client-side state handling so cleanup does not leave executable residue or stale trust state. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Logout and compromise cleanup workflows should be observable and verifiable in logs. |
| Recommendation — Log session-ending and recovery actions so cleanup events are traceable during incident response. | ||
Practitioner Guidance
What to verify: Confirm which directives your application actually needs to clear, then test the result against the real browser storage your app uses, including cookies, cache, IndexedDB, local storage, and any offline or embedded state. A broad directive set is only appropriate when you have verified that the user journey can tolerate the reset.
Decision rule: If the header is being used after compromise or account recovery, pair it with server-side session invalidation and credential reset, because client-side clearing alone does not revoke access already granted elsewhere. If the goal is simple logout, keep the directive set narrow enough to avoid unnecessary disruption.
Practitioner takeaway: Clear-Site-Data is most effective when it is part of a session-ending or recovery workflow, not a substitute for revocation. Treat it as browser cleanup with real user-impact trade-offs, and validate the exact state you are asking the browser to discard.