Cookie Security Checker
Check whether your cookies are configured securely. Paste Set-Cookie headers or enter a URL, and each cookie is graded on the flags that protect it: Secure (HTTPS only), HttpOnly (no JavaScript access), SameSite (cross-site requests), the __Host- and __Secure- prefix rules, Domain scope and lifetime. Session and authentication cookies are recognised by name and held to a stricter standard. Cookie values are never shown – for URLs they are removed on the server.
- Encrypted connection
- No sign-up
- Free to use
How to use Cookie Security Checker
- Paste Set-Cookie headers or enter a URL.
- Click Check cookies.
- Fix cookies graded D or F.
- Re-check after deploying.
Cookie Security Checker features
Per-cookie grade
With explained findings.
Prefix rules
__Host- and __Secure-.
Session detection
Stricter checks for auth cookies.
Values hidden
Only names and flags.
Paste mode
Analysed in your browser.
Lifetime
Session, days or expired.
When to use Cookie Security Checker
- Securing login sessions.
- Security reviews before launch.
- Framework configuration checks.
- PCI and OWASP checklists.
Cookie Security Checker FAQ
Which flags should a session cookie have?
Secure, HttpOnly, SameSite=Lax or Strict, Path=/ and ideally the __Host- prefix.
What does SameSite do?
It controls whether the cookie is sent with cross-site requests, which protects against CSRF.
Why avoid Domain=?
It sends the cookie to every subdomain, including ones that may be less secure.
How is this different from the website cookie checker?
That tool focuses on purposes and consent; this one on security flags, including pasted headers.
What does the __Host- prefix do?
A cookie named with __Host- must be Secure, have Path=/ and no Domain attribute, so it cannot be set or overwritten by subdomains.
What does SameSite=Lax do?
The cookie is sent with top-level navigation from other sites, such as following a link, but not with cross-site form posts or embedded requests, which blocks most CSRF attacks.
When is SameSite=None needed?
For cookies that must work in cross-site contexts, such as embedded widgets or single sign-on. It requires the Secure flag.
Should every cookie be HttpOnly?
Every cookie JavaScript does not need to read – especially session and login cookies. Preference cookies read by scripts cannot be HttpOnly.
Small flags, big protection
Most session hijacking and CSRF attacks rely on a missing cookie flag. Setting them correctly costs nothing.
Each cookie is graded on the flags that protect it: Secure keeps it off plain http, HttpOnly hides it from JavaScript, and SameSite limits when it is sent with cross-site requests. The __Host- and __Secure- name prefixes enforce stricter rules that browsers check themselves.
Session and authentication cookies need all three protections; a session cookie readable by JavaScript can be stolen through a single XSS flaw. Very long lifetimes and broad Domain attributes increase exposure.
Paste Set-Cookie headers to analyse them in your browser, or enter a URL you own or are allowed to test.
For login and session cookies, a strong default is Secure, HttpOnly, SameSite=Lax and the __Host- prefix, with a lifetime matching your session policy. Cookies used by JavaScript, such as preferences, cannot be HttpOnly, so they should never contain sensitive data.
Check cookies after adding a new framework, authentication provider or analytics tool, since each may set its own cookies with different defaults.
Remember that cookie flags protect the cookie, not the data behind it: sessions should also expire on the server, and logging out should invalidate the session there, not only delete the cookie in the browser.