Paste one or more raw Set-Cookie header lines to get a graded security report for each cookie. It audits the Secure and HttpOnly flags, the SameSite setting, how wide the Domain scope is, the __Host- and __Secure- name prefixes, and how long the cookie lives. It reads attributes only, so it explains the tradeoffs instead of guessing your app's intent.
A Set-Cookie header looks simple, but the attributes after the name and value decide whether the cookie is a safe session credential or an easy target. The browser only honors the attributes you actually set, so a missing flag is a silent default, not a no op. This tool parses each cookie and audits the attributes that matter, drawing on the cookie handling rules in RFC 6265 and the prefix and SameSite work in the 6265bis draft. It reads attributes only and cannot know your application's intent, so it explains the tradeoff for each setting rather than handing down an absolute verdict.
The Secure attribute tells the browser to send the cookie only over HTTPS. Without it, the cookie can ride along on a plain HTTP request, where anyone on the network path can read it. For a session cookie that is the whole credential in the clear. Setting Secure is the baseline, and a missing one is treated as a failing check.
The HttpOnly attribute hides the cookie from JavaScript, so document.cookie cannot read it. That matters because a cross site scripting bug can run script in your page, and a script that can read the session cookie can hand it to an attacker. Session cookies should be HttpOnly. The exception is a cookie the front end must read on purpose, so the tool raises this as something to confirm rather than an outright failure. For the bug class this defends against, see what cross site scripting is and how it works.
The SameSite attribute controls whether the browser attaches the cookie to a request that another site started. Strict never does, Lax sends it only on top level navigations, and None sends it on every cross site request. A cookie set to SameSite=None must also be Secure, and modern browsers reject it otherwise. When the attribute is missing, modern browsers fall back to Lax, but older ones do not, so the tool recommends setting it explicitly. This is the main lever against cross site request forgery.
If a cookie sets a Domain attribute pointing at a parent or registrable domain, the browser shares it with every subdomain of that domain. That widens the blast radius: any one vulnerable subdomain can read or set the cookie. A cookie with no Domain attribute is host only, bound to the exact host that set it, which is the safer default. The risk of a wide scope is tied directly to subdomain takeover, where an attacker who controls a forgotten subdomain inherits any cookie scoped to the parent.
The browser enforces two name prefixes. A cookie named with __Secure- is only accepted when it carries the Secure flag. A cookie named with __Host- is stricter: it must be Secure, must have Path set to slash, and must have no Domain attribute, which locks it to the exact host that set it and stops a subdomain from overwriting it. The __Host- prefix gives the strongest binding for a session cookie. If a prefixed cookie breaks its own rules, the browser silently drops it, so the tool flags that mismatch.
A cookie with no Max-Age or Expires is a session cookie that disappears when the browser closes. Adding a far future Expires or a very large Max-Age turns it into a persistent credential that keeps working for a long time. For a sensitive cookie, a long lifetime is a long lived liability if it leaks, so the tool raises it for review.
Each cookie is graded on its own. Every graded check contributes a weighted share of a score out of one hundred. A pass earns its full weight, a weak setting earns part of it, and a dangerous one earns none, while purely advisory notes do not move the score. The grade is a fast signal about the cookie as it was set, not a verdict on the whole application. Because the tool reads attributes only, it cannot tell whether a cookie is meant to be read by the front end or shared across subdomains on purpose, so judging real safety still means understanding how your app uses each cookie, which is the kind of context an AI security testing approach reasons about rather than pattern matching one header. For the wider set of session and access boundaries attackers probe, see the access control writing.