Safety
Clear-Site-Data vs Cookie Expiry on Logout
July 7, 2022
Clear-Site-Data vs cookie expiry on logout is two brooms. Setting the session cookie to Max-Age=0 (or an expired date) tells the browser to drop that cookie. Clear-Site-Data on the logout response can instruct supporting browsers to clear cookies, storage, and cache for the origin — including localStorage tokens a SPA left behind. You usually want both: expire the HttpOnly session cookie in the app, and send Clear-Site-Data if you also stored client-side state. RoastMyOpsec grades Set-Cookie on the landing page you paste. It does not log in or hit /logout, so a clean roast is not a logout-hygiene certificate.
The practical difference
Cookie expiry is precise: one name, one host, one path. Miss a Domain or Path mismatch and the 'deleted' cookie is still there. Clear-Site-Data is blunt: cookies, cache, storage, executionContexts depending on the quoted values. It can surprise a marketing site that shares the origin with an app — you may wipe more than the session.
SPAs that put JWTs in localStorage cannot be saved by Max-Age=0 on a cookie they never used. See localStorage vs HttpOnly.
How to choose based on the product
Cookie-session brochure plus WordPress: expire wordpress_ and session cookies on logout; Clear-Site-Data is optional. SPA on the same origin as the marketing site: logout must clear storage, not only the cookie; consider Clear-Site-Data "storage" plus explicit cookie expiry. Shared origin with a shop: do not blindly clear cache for the whole e-commerce CDN hostname.
| Control | What it clears | What it misses | Takeaway |
|---|---|---|---|
| Set-Cookie Max-Age=0 | That cookie name/path/domain | localStorage, other cookie names, Service Worker | Required for cookie sessions |
| Clear-Site-Data cookies | Origin cookies (supporting browsers) | HttpOnly cookies on another host; some browsers' gaps | Pair with explicit expiry |
| Clear-Site-Data storage | localStorage / IndexedDB class data | Tokens in memory until reload | Needed if you ever stored JS-visible sessions |
| Server session revoke | The server's idea of login | A stolen cookie still sent until expiry | Do this too — headers are not enough |
What a public roast will not see
Logout is an authenticated POST. The free cookie check looks at Set-Cookie on the URL you submitted. Confirm logout in the app: 303 to a public page, expired session cookie, optional Clear-Site-Data, and a server-side session kill.
Common mistakes
The first mistake is client-side-only 'logout' that deletes localStorage and leaves the HttpOnly cookie.
The second mistake is Clear-Site-Data on the homepage for everyone.
The third mistake is expiring the cookie with the wrong Path so the session cookie survives.
Free audit the URL you own
RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.
Free audit nowFAQ
- Is Clear-Site-Data better than expiring the cookie?
- They stack. Always expire the session cookie and revoke the server session. Add Clear-Site-Data when client storage is in play.
- Will RoastMyOpsec test my logout?
- No. It does not log in. Check Set-Cookie on the public landing response, then test logout yourself.
- Does Clear-Site-Data log users out of other subdomains?
- It is origin-scoped in supporting browsers, not a whole eTLD+1 wipe. Cookie Domain=.example.com is a separate mistake — see cookie flags and prefixes.