Cookie Security Checker
Are your session cookies protected? We read the Set-Cookie headers your site returns and check each cookie for the Secure, HttpOnly and SameSite flags — the three settings that stop session theft and cross-site attacks — with a plain-English fix for every gap. Free, passive, no signup.
This tool reads the Set-Cookie headers your server already returns on its homepage (and any redirect hops) — the same thing any browser receives. It performs no intrusive testing and only checks cookies on domains you point it at. Cookies set only after login are out of scope for this passive check.
What this checker looks at
Three cookie attributes do most of the work of keeping a session safe. Secure stops the cookie ever being sent over plain HTTP, where anyone on the network could read it. HttpOnly hides the cookie from JavaScript, so a single cross-site scripting (XSS) bug can't read a logged-in user's session token. SameSite controls whether the cookie rides along on cross-site requests, which is the core defence against cross-site request forgery (CSRF).
This checker reads the cookies your site sets on a normal homepage request — exactly what a visitor's browser receives — and grades each one against current best practice. It also checks the __Host- / __Secure- name prefixes and flags the genuine error of SameSite=None without Secure, which modern browsers silently drop.
It reports configuration facts, not a vulnerability verdict, and it deliberately calibrates severity to real risk: a login cookie missing HttpOnly is serious, but a missing SameSite is only a minor hardening gap because browsers now default to Lax. Cookies that are meant to be read by JavaScript — CSRF double-submit tokens, analytics — are recognised and not flagged for missing HttpOnly.
How to read the result
The grade is a quick summary; the findings below it are what matter. Each finding pairs a plain-English explanation with the exact Set-Cookie line to fix it and a link to a step-by-step guide. Work top-down — anything marked high is a real session-theft or broken-cookie risk and should be fixed first; info-level notes are optional hardening. After you deploy a change, re-run the check to confirm the new flags are live.
How to secure your cookies
Set the flags where your application or framework issues the cookie, then re-test. For a session cookie, the safe baseline is all three:
- Secure — only send the cookie over HTTPS. Add it to every cookie on an HTTPS site: Set-Cookie: sid=…; Secure.
- HttpOnly — hide the cookie from JavaScript so XSS can't steal the session: Set-Cookie: sid=…; HttpOnly. (Omit only for cookies the front-end must read, such as a CSRF double-submit token.)
- SameSite=Lax (or Strict) — stop the cookie riding cross-site requests, which blocks CSRF. Lax is a sensible default; use None only for genuine cross-site cookies, and then Secure is mandatory.
- Use the __Host- prefix for session cookies where you can — Set-Cookie: __Host-sid=…; Secure; Path=/ (no Domain) — for the strongest browser-enforced guarantees.
- Re-scan after each change to confirm the flags are being served on the live site.
Want the full background? Read the in-depth guide →
Frequently asked questions
Is this cookie checker free?
Yes — completely free and open, with no account, no email, and no signup. Enter a domain and you get the result immediately. The check is passive: it reads the Set-Cookie headers your server already returns on a normal request (and on any redirect hops, such as a redirect to a login page), exactly the way a browser does. There is nothing to install and no access to your server required.
Why is a missing SameSite only a minor warning?
Because modern browsers default cookies to SameSite=Lax when the attribute is absent, so a missing SameSite no longer leaves you wide open to CSRF the way it did years ago — it is a hardening gap, not an active vulnerability. We grade it as informational and say so plainly, rather than inflating it to look scarier than it is. A login cookie without Secure or HttpOnly, by contrast, is genuinely exploitable, so those are graded high.
My cookie has no HttpOnly but wasn't flagged — why?
Some cookies are meant to be read by JavaScript and would break if they were HttpOnly. The classic case is a CSRF double-submit token (XSRF-TOKEN, csrf_token and similar), which the front-end has to read to echo back in a request header; analytics cookies are similar. The checker recognises these and does not flag them for a missing HttpOnly flag — it still checks them for Secure and SameSite.
What does SameSite=None without Secure mean?
It's a real misconfiguration. A cookie set with SameSite=None is asking to be sent on cross-site requests, and every modern browser requires that such a cookie also carry the Secure flag. Without Secure, the browser silently rejects the cookie — so it likely isn't working at all. The fix is to add Secure alongside SameSite=None.
Do you check cookies set after login?
No. This is a passive, unauthenticated check: it only sees the cookies your site sets for an anonymous visitor on the homepage and any redirect hops. Cookies issued after you sign in are out of scope here — inspecting those is part of an authenticated review, not this public tool.
Related tools
Check the full attack surface — free.
The full external scan goes beyond cookie flags: headers, TLS, subdomains, open services, exposed secrets, and known-exploited CVEs, run under your authorization.