Clear-Site-Data
Set per response by your application, so it isn't part of the builder or the grade. Open the builder →
Logging a user out server-side does nothing about what the browser still holds: cookies for sibling subdomains, localStorage, IndexedDB, service workers, and a cache full of their data. Clear-Site-Data tells the browser to throw it away. The value is a list of quoted directives — "cookies", "storage", "cache", "executionContexts", or "*" for everything. Send it on the logout response (and on account-deletion or session-revocation responses); it only works over HTTPS, and it is deliberately scoped to the origin sending it. Support for the individual directives varies by browser — "cookies" and "storage" are the dependable ones, so treat this as defence in depth rather than a guarantee, and never as a substitute for invalidating the session on the server. Because it belongs on one endpoint rather than on every response, it is reference-only here. MDN
Example
Clear-Site-Data: "cookies", "storage"Attributes
| Attribute | What it does |
|---|---|
"cookies" | Clears cookies and HTTP auth credentials for the origin — and, unlike the other directives, for the whole registrable domain. The one to send on logout. |
"storage" | Clears localStorage, sessionStorage, IndexedDB, Cache Storage, service-worker registrations, and the rest of the origin’s DOM storage. |
"cache" | Clears the network cache for the origin. Browser support is the patchiest of the set; do not rely on it alone to hide cached pages. |
"executionContexts" | Reloads any open browsing contexts for the origin, so a stale tab cannot keep running with pre-logout state. |
"*" | Everything above. Simple and blunt — fine for logout, but it will also evict caches the user would rather keep. |
Scoring
Not scored. The grade covers headers you can set once in server config; this one is emitted per response by the application, so a scanner can't judge it from a single request.