Cookie Security Check

Cookie Security Check fetches the Set-Cookie headers a website sends to the browser and inspects whether each cookie carries proper security attributes such as Secure, HttpOnly and SameSite. It helps you quickly tell whether session cookies or login tokens are exposed to theft or tampering.

Just enter a URL and the server safely requests the page and analyzes the cookies in the response headers. The cookie values themselves are not used for judgment — only whether key attributes are present, shown as an OK or warning status. Results are briefly cached for speed.

Three core security attributes

• Secure: sends the cookie only over HTTPS. Without it, the cookie can leak over plain HTTP and is vulnerable to man-in-the-middle attacks. Essential for login and session cookies.
• HttpOnly: blocks JavaScript (document.cookie) from reading the cookie, making session theft far harder even if an XSS flaw exists.
• SameSite: controls whether the cookie is sent on requests from other sites. Strict/Lax greatly reduce CSRF risk, while None must always be paired with Secure.

How to read the results

For each cookie, Secure and HttpOnly being set is shown as OK, and missing as a warning. The SameSite value (Strict/Lax/None) is shown too. For sensitive auth cookies, treat Secure + HttpOnly + SameSite=Lax (or Strict) as the recommended baseline, and check that the domain, path and expiry (Expires/Max-Age) are not broader than intended. Alongside cookies, run the security headers checkerto review response headers like HSTS and CSP and gauge the site's baseline protection in one pass.

Cookie name prefixes (__Secure- / __Host-)

Some security rules are enforced by the cookie name itself. Browsers reject any prefixed cookie that breaks the rule, so when one of these prefixes shows up in the results, the corresponding attribute combination is effectively guaranteed.

Walking through a real Set-Cookie line

Suppose the server sends this header:

Set-Cookie: sid=ab12cd; Path=/; Secure; HttpOnly; SameSite=Lax; Max-Age=3600

• sid = a session identifier (the value ab12cd is not used for judgment).
• Secure ✓ + HttpOnly ✓ → both core attributes present, so it shows as OK.
• SameSite=Lax → sent on external link clicks, but not on images, iframes, or cross-site POSTs → low CSRF risk.
• Max-Age=3600 → expires in one hour. With no Domain attribute, the cookie is bound to exactly the issuing host (the safest default).

If the same line dropped HttpOnly and added Domain=.example.com, the token could be read via XSS and would spread to every subdomain — both warning signals.

Common pitfall

The most common trap is widening the Domain attribute on purpose. OmitDomain entirely and the cookie is sent only to the exact issuing host (app.example.com); write Domain=.example.com and it spreads to every subdomain. A single XSS on a lower-security host like blog.example.com can then expose the login cookie. Also note you will never see a __Host- cookie that looks like it is missing Secure — if that prefix appears, the browser has already verified both Secure and Path=/, so it is safe to trust.