Cookie Security Checker

Report

Raw Set-Cookie headers

Common questions

What actually happens if a cookie is SameSite=None without Secure?

The browser refuses to set the cookie at all. SameSite=None is how a site opts in to a cookie being sent on cross-site requests -- embedded widgets, cross-site payment flows, federated login -- and the current SameSite specification requires Secure alongside it. Chrome, Firefox, and Safari all enforce that requirement by rejecting the Set-Cookie header outright when Secure is missing, so the failure mode is not a weaker cookie -- the feature the cookie exists for (an embed staying logged in, a cross-site checkout remembering its session) simply breaks, silently, with no error visible to the person who hit it. More background: why a SameSite=None cookie disappears instead of just weakening.

What do the __Host- and __Secure- cookie name prefixes actually enforce?

They are a browser-enforced contract on the cookie's own name, not just documentation. A cookie named __Secure-... must carry the Secure attribute or the browser refuses to store it. A cookie named __Host-... must carry Secure, must not carry a Domain attribute, and must have Path=/ -- again, violate any one of those and the browser refuses to store it. The prefixes exist so that a server can guarantee, just by checking the incoming cookie's name, that it could only have been set by the same secure origin -- a guarantee that is worthless if this portfolio's tool (or any other) only checked the prefix looked right and not that every rule behind it was actually met.

Why is a missing Secure or HttpOnly attribute only a notice, not a danger finding?

Because whether it matters depends on context this tool cannot see from response headers alone. A missing Secure attribute widens exposure to anyone who can observe a future plain-HTTP request to the same host; a missing HttpOnly attribute widens the blast radius of any XSS bug the site might have. Both are real, worth fixing, and reported -- but neither is an unconditional fact about what the browser will do the way SameSite=None-without-Secure and a broken __Host-/__Secure- prefix are, which this tool reserves 'danger' for.

Why can't Set-Cookie headers just be joined into one string and split on commas like other headers?

Because a comma can appear inside a single Set-Cookie header's own value -- the Expires attribute's date format is "Expires=Wed, 21 Oct 2026 07:28:00 GMT", comma included. Node's http and https clients already know this and expose set-cookie as an array of the individual raw header values rather than folding repeated headers into one comma-joined string the way they do for every other header name. This tool reads that array directly; a naive implementation that reused the comma-join-then-split pattern used for ordinary headers would silently corrupt any cookie carrying an Expires date.

Does a clean report mean the site's cookies have no security issues?

No. This checks a specific, well-documented set of Set-Cookie attribute patterns from one response -- it is not a full security assessment, does not crawl other pages on the site, and cannot see a misconfiguration this tool's checks don't happen to cover (response security headers like CSP and X-Frame-Options are out of scope here -- see security-headers-check for those). Treat a clean report as evidence about these specific patterns, not a determination that the site's cookies are secure.