Paste Set-Cookie headers and inspect the flags
Paste one or more Set-Cookie response headers below; the tool parses Secure, HttpOnly, SameSite, persistence and __Host-/__Secure- prefixes in the browser and flags session cookies without HttpOnly and SameSite=None without Secure. No network, no upload; cookie values are dropped immediately.
Not checked yet.
Running built-in self-test…
Rules
| Measure | Rule | Boundary |
|---|---|---|
| Cookie | Every non-empty line, with an optional Set-Cookie: prefix removed | String parsing only, no request sent |
| Secure / HttpOnly | Attribute present | Browser enforcement not tested |
| SameSite | Lax/Strict/None recorded; undeclared listed separately | Undeclared means Lax by browser default |
| Persistent | Max-Age or Expires present | Session cookies excluded |
| Prefix | Name starts with __Host- or __Secure- | Prefix constraints not validated |
| Warning | Missing Secure / session without HttpOnly / None without Secure | A hint, not a vulnerability verdict |
The tool only parses strings: it does not judge whether a cookie is read by scripts or used for tracking, and it does not verify that the server actually enforces these flags. It shares its rules with the Python probe scripts/cookie_flag_probe.py; the Node assertions live in scripts/test_cookie_check.js (13 checks), run with node scripts/test_cookie_check.js.
Privacy: parsing happens on this page with no network request; the CSV export keeps names and flags only, never values. Opening the page with #sample fills the sample automatically for comparison.
Related: the homepage cookie-flag audit (20 cookies on 10 sites), the homepage script-hygiene audit, and the homepage privacy and analytics pilot.
Frequently asked questions
Does the tool upload cookies?
No. Parsing runs entirely in the browser with no network request; values are dropped immediately and both the page and the CSV export keep names and flags only.
Is missing SameSite a defect?
Not necessarily. Modern browsers treat an undeclared cookie as Lax by default; the tool reports “not declared” separately so you can tell defaults from explicit policy.
Why highlight Secure separately?
On an HTTPS site a cookie without Secure can still travel over a plaintext request, which makes it the cheapest fix.
How are session cookies detected?
By name keywords (sess, session, token, JSESSIONID, PHPSESSID, ASP.NET_SessionId). This is a hint, not a security conclusion.
Does it accept multiple lines?
Yes, one Set-Cookie per line, with or without the Set-Cookie: prefix. Blank lines are ignored.