About the Cookie Security Checker
Cookies often carry session tokens, so their attributes decide who can read them and when the browser sends them. This checker requests a URL, follows every redirect, and grades each Set-Cookie header it sees, noting which request set it.
For each cookie it reports Domain and Path, the expiry (Max-Age wins over Expires; no expiry means a session cookie), Secure, HttpOnly, SameSite and Partitioned, plus the size. It flags cookies browsers reject outright, such as SameSite=None without Secure, __Host- and __Secure- cookies that break their prefix rules, a Domain that doesn't cover the host, and cookies over 4096 bytes. It warns about missing protections, a Domain that also sends the cookie to every subdomain, and lifetimes over 400 days, which browsers cut short. Cookie values are never shown or stored, only their length.
How to use it
- Enter a URL, ideally a page that sets cookies, such as a login page.
- Select Check cookies.
- Open each cookie's checks and apply the fixes marked Fail first.
Examples
- Check github.com: sets session and preference cookies, some with
Domain=.github.com, which reaches every subdomain. - Check example.com: sets no cookies at all.
Common questions
Why are some of my cookies missing?
The check only sees Set-Cookie response headers. Cookies set by JavaScript, by API calls the page makes later, or after you sign in aren't visible to a server-side request.
Does every cookie need HttpOnly?
Session and authentication cookies should have it. A cookie your own JavaScript must read, such as a CSRF token or a preference, can't.
What does SameSite do when it isn't set?
Chrome and Edge treat a missing SameSite as Lax. Firefox and Safari don't, so set it explicitly.
Related tools
- Security Headers Checker: grade the response headers of the same page.
- Redirect Checker: see every hop a URL takes.
- CSP Evaluator: check the page's Content-Security-Policy.