Cookie Security Checker
Check the cookies a site sets for Secure, HttpOnly and SameSite, and see exactly what each missing attribute exposes.
What this cookie security checker looks for
Enter a URL and this tool sends one ordinary GET request, then parses every Set-Cookie header the server sends back — name, value, and every attribute attached to it. Cookies are one of the few places where a single missing keyword has a concrete, well-understood consequence, so each attribute below is checked against what actually goes wrong without it, not against a generic best-practice list.
Secure
Without Secure, a cookie set on an HTTPS site will still be sent if the browser ever makes a plain HTTP request to the same host — a stray http:// link, a misconfigured redirect, a network attacker forcing a downgrade. Anyone positioned on the network path between the browser and server at that moment can read or tamper with the cookie in transit. This check only runs when the site itself was reached over HTTPS; judging Secure on a plain-HTTP response wouldn't mean anything.
HttpOnly
A cookie without HttpOnly can be read by any JavaScript running on the page — including script an attacker injects through a cross-site scripting bug. For a session or auth cookie, that's the whole game: document.cookie hands the attacker a working session in one line. This tool treats cookie names containing session, sess, auth, token, jwt, sid or login as session-like and grades a missing HttpOnly on those higher than on an ordinary preference cookie.
SameSite
SameSite decides whether a cookie rides along with a request that originated from a different site — the mechanism cross-site request forgery depends on. Current browsers default an unset SameSite to Lax, which is better than nothing, but relying on a default is fragile: it's silent, it has changed before, and it varies across older or less common browsers. SameSite=None is sometimes genuinely required — a payment iframe, an SSO callback — but browsers reject it outright unless Secure is also set, so the two have to travel together or the cookie simply stops being sent.
Domain scope
An explicit Domain attribute, especially one written with a leading dot, shares the cookie with every subdomain of that domain, not just the host that set it. That's sometimes deliberate — single sign-on across subdomains needs it — but it also means a single compromised, abandoned, or misconfigured subdomain can read and forge the cookie. Leaving Domain unset makes the cookie host-only, which is the tighter default.
Expiry
A cookie with no Max-Age or Expires is a session cookie — gone when the browser closes, which is fine and common. The risk runs the other way: a cookie set to last a year or more stays valid for just as long if a copy of it is ever stolen, from a shared computer, a log file, or a backup. This tool only flags expiry when it's unusually long, never when it's absent.
__Host- and __Secure- prefixes
These prefixes turn a naming convention into a browser-enforced guarantee. A cookie named __Secure-token is refused by the browser unless it carries Secure. A cookie named __Host-session has to go further — Secure, no Domain attribute, and Path=/ — which closes off a class of cookie-injection tricks where a cookie set on a subdomain or a narrower path overrides one meant for the whole site. Using the prefix correctly is a pass; using the name without meeting its requirements means the browser is silently refusing to set the cookie at all.
A reasonable default for a session cookie
Set-Cookie: __Host-session=<opaque-token>; Secure; HttpOnly; SameSite=Lax; Path=/No Domain attribute (so it is host-only and satisfies __Host-), no explicit expiry (so it dies with the browser session unless you deliberately want persistence), and SameSite=Lax unless the cookie genuinely needs to arrive on cross-site requests.
How the grade is calculated
Every check starts the report at 100 and deducts based on severity — a missing Secure or HttpOnly on a session-like cookie costs far more than an informational note about Path. Scores of 90+ earn an A, 75 a B, 55 a C, 35 a D, and below that an F. A site with no cookies at all gets a clean pass — there's nothing here to misconfigure.
Frequently asked questions
What do Secure, HttpOnly and SameSite actually do?
Secure stops a cookie being sent over plain HTTP. HttpOnly stops client-side JavaScript from reading it, which matters if an XSS bug ever runs on the page. SameSite controls whether the cookie is sent along with requests that originate from another site, which is central to preventing cross-site request forgery.
Why does HttpOnly matter more for some cookies than others?
It's about what an attacker gains by reading the cookie. A session or auth cookie readable via document.cookie can be exfiltrated by a single XSS bug and used to hijack the account outright. A UI preference cookie leaking the same way is a much smaller problem, so this tool grades missing HttpOnly higher on names that look session-like.
Is a session cookie with no expiry a problem?
No — that's the normal case. A cookie with no Max-Age or Expires is a session cookie: the browser discards it when the tab or browser closes. This tool only flags an expiry as a problem when it's unusually long, not when it's absent.
What are the __Host- and __Secure- prefixes?
They're a browser-enforced guarantee baked into the cookie's name. A cookie named __Secure-x is refused by the browser unless it also has Secure set. __Host-x goes further — Secure, no Domain attribute, and Path=/ — which means the cookie can't be overridden by a subdomain or a different path, a trick sometimes used in cookie-injection attacks.
Is this cookie checker free?
Yes, completely free with no sign-up. Enter a URL and get the full report on every cookie the response sets.
Does this tool log in or authenticate to see my cookies?
No. It sends one anonymous GET request, the same as a first-time visitor's browser would, and reads whatever cookies the server sets in response to that. It cannot see cookies that are only set after a login form is submitted.
Can I check a site I do not own?
Yes — reading response headers from a single ordinary GET request is exactly what every browser does on every page load. It is passive and does not touch anything on the server. Only act on the findings for sites you are responsible for.