Cookie security checker

The flags that matter

Secure means the browser only sends the cookie over https. Without it, anyone on the same Wi-Fi network can read the cookie the moment the browser makes a plain http request. HttpOnly hides the cookie from JavaScript, so a cross-site scripting bug cannot simply read your session. SameSite controls whether the cookie is sent when another site triggers a request to yours, which is the mechanism behind cross-site request forgery.

A session cookie with all three is the baseline. A cookie that identifies a logged-in user without them is a high-severity finding in most security tests.

Prefixes and scope

Naming a cookie with the __Host- prefix makes the browser enforce a strict shape: it must be Secure, have Path=/ and must not have a Domain attribute. That binds it to your exact host and stops a subdomain, or an attacker who controls one, from overwriting it. __Secure- only requires Secure. A Domain attribute shares the cookie with every subdomain, including ones you may have forgotten.

Lifetime matters too. Browsers such as Chrome limit cookie lifetimes to about 400 days, and a login cookie that lives for a year is useful to a thief for a year.

Where to get the headers

Open your site, open the browser developer tools, go to the Network tab, reload, click the first request and copy each Set-Cookie line from the response headers. Paste one per line. The checker flags session-like names (session, token, auth, sid and so on) more strictly than other cookies.