Cookie security check
See every cookie your site sets and whether it carries the Secure, HttpOnly, and SameSite flags — the three attributes standing between your users and session hijacking. Names only; we never read values.
The cookie is the session
Whoever holds a user's session cookie is that user — no password needed.
The three flags are what decide how stealable it is: Secure keeps it off the network, HttpOnly keeps it away from scripts, SameSite keeps other sites from borrowing it.
Each is one word in the Set-Cookie header, and each closes a different way of walking off with an account.
Auth libraries mostly get this right. The gaps show up in the cookies your own code sets — the quick “remember this” flag added at midnight, the analytics cookie from a snippet — which is exactly what a listing like this makes visible.
Cookies are one layer. The free report checks the rest.
Run the full scan free — security headers, TLS, DNS, exposed subdomains, email spoofing protection and more, graded A to F, with a copy-paste fix for every finding.
Cookie security, answered
What do the Secure, HttpOnly, and SameSite cookie flags do?
Three separate locks. Secure means the cookie is only ever sent over HTTPS, so it can't be read off the network.
HttpOnly means JavaScript on the page can't read it, so an injected script can't steal it.
SameSite controls whether the browser attaches it to requests coming from other sites, which blunts cross-site request forgery. A session cookie ideally wears all three.
Why does the HttpOnly flag matter so much for session cookies?
Because it decides what an XSS bug costs you.
If an attacker gets a script running on your page and your session cookie is readable by JavaScript, they copy it and are logged in as your user from their own machine.
With HttpOnly set, the same bug can deface the page but can't walk away with the session. It's one attribute, and it's the difference between an incident and a breach.
What does SameSite=Lax vs Strict vs None mean?
Lax (the modern default) sends the cookie on normal top-level navigation to your site but not on cross-site subrequests — good CSRF protection with no login weirdness.
Strict never sends it from another site, maximum protection but users arriving from links may appear logged out for a moment.
None sends it everywhere — needed for third-party embeds — and browsers require Secure alongside it, otherwise the cookie is rejected entirely.
Why does this checker show no cookies for my site?
It checks what an anonymous first visit receives, and many apps set nothing until someone logs in or hits a specific page.
That's the best possible configuration for privacy and caching.
Try the URL of your login page or app dashboard — those are the responses that usually carry the session cookie worth checking.
Can this tool see my users' cookie values?
No. It reads only cookie names and attributes from the Set-Cookie response headers — the same thing any browser receives.
Values are never inspected or stored. And it sees only what your server sends to a fresh anonymous visitor, never anything from a logged-in session.
How do I set these flags in my framework?
Everywhere cookies are set there's an options object: Express is res.cookie(name, value, { secure: true, httpOnly: true, sameSite: 'lax' }); Next.js route handlers take the same options in cookies().set(); Django and Rails have SESSION_COOKIE_SECURE-style settings.
If an auth library sets cookies for you (Supabase, NextAuth, Clerk), it almost certainly does this correctly already — the flags to audit are the ones your own code sets.
Related reading
Other free checks
one request to your site · cookie names and flags only, never values · nothing stored