Why it matters
Session cookies are the keys to your users' accounts. A cookie without HttpOnly can be stolen by any script injected into the page; one without Secure can travel over plain HTTP; and a broad Domain shares it with every subdomain.
This analyser parses each Set-Cookie header the way browsers do, checks it against the current cookie rules (including the 400-day lifetime cap and prefix rules), and writes a corrected version, so a code review or a pen-test finding takes minutes to fix.
How it works
- InputOne or more Set-Cookie headers
- In your browserChecked for Secure, HttpOnly, SameSite and prefixes
- OutputA report per cookie and a corrected header
Where it fits in a designer's workflow
- Plan
- Design
- Build
- Test
- Launch
By the numbers
Show the numbers as a table
| Cookie | Fail | Worth fixing | Pass |
|---|---|---|---|
| session | 3 | 2 | 0 |
| __Host-csrf | 0 | 0 | 4 |
| theme | 0 | 1 | 3 |
| tracking id | 3 | 2 | 0 |
How to use it
- Paste one or more Set-Cookie headers.
- Enter the site's host and whether it's HTTPS.
- Read the issues for each cookie.
- Copy the corrected headers.
FAQ
Which SameSite value should I use?
Lax for most session cookies. Strict for sensitive actions. None only when a cookie must work in cross-site iframes, and it then needs Secure.
What does the __Host- prefix do?
Browsers only accept a __Host- cookie if it's Secure, has Path=/ and no Domain, which stops subdomains overriding it.
Why is my long expiry shortened?
Browsers now cap cookie lifetimes at 400 days, whatever Max-Age or Expires says.
Is anything sent?
No. The headers are parsed in your browser.
