Website Cookie Inventory Scanner

What this shows you

Every cookie a page sets on a first, unauthenticated visit - with its full attribute set laid out: Secure, HttpOnly, SameSite, the domain and path it is scoped to, how long it lives, and whether a __Host- or __Secure- prefix is actually being honoured.

It is the inventory you need before you can answer the two questions that matter: what is this site storing in my visitors' browsers, and is any of it scoped more widely than it needs to be.

Cookie values are never shown

The tool reports each cookie's name and the length of its value, never the value itself. That is deliberate and not negotiable: a session cookie is a credential, and a tool that printed one into a page - or into an export somebody emails around - would be handing out exactly the thing the cookie exists to protect. The underlying service redacts before the value ever reaches this page.

Observed versus inferred

The attributes are observed. They were read directly from the Set-Cookie header and are facts.

The purpose column is inferred, and the tool labels it that way every time it appears. Cookie names are conventional rather than standardised: something called sid is probably a session identifier and _ga is almost certainly Google Analytics, but “probably” is the honest word. Presenting a guess as a fact is how consent tooling ends up with confidently wrong cookie declarations, so the distinction is kept visible rather than collapsed into a single confident answer.

What the attributes mean

• Secure - the cookie is only ever sent over HTTPS. Without it, any plain HTTP request to the domain sends the cookie in the clear, where it can be read off the network. There is no case for omitting it on a site served over HTTPS.
• HttpOnly - script cannot read the cookie. For a session cookie this is what stops a cross-site scripting bug becoming account takeover. Omit it only where your own front-end genuinely needs to read the value.
• SameSite - whether the cookie travels on cross-site requests. Lax is the sensible default for a session cookie. None is required for genuine cross-site use and must be paired with Secure or browsers reject it outright.
• Domain - a leading dot sends the cookie to every subdomain. That includes ones run by another team, hosted elsewhere, or pointing at something abandoned. A host-only cookie, with no Domain attribute at all, is the tighter default.
• Prefixes - __Host- and __Secure- are enforced by the browser rather than by convention. __Host- requires Secure, a path of / and no Domain, which makes the cookie impossible for a subdomain to overwrite. The tool reports whether a prefixed cookie actually meets its requirements, because one that does not is silently rejected.

Subdomain scope is the finding people miss

A cookie scoped to .example.com is readable and writable by every subdomain. If any one of them is compromised - an old marketing site, a staging box, a third-party service on a CNAME - that subdomain can read the cookie, and can also set one that overwrites yours on the parent domain. Session fixation through a forgotten subdomain is a real and recurring pattern, and it is invisible unless you look at the scope.

Limitations

This checks one URL, unauthenticated, once. Sites set most of their interesting cookies after login, and a home page that sets nothing tells you nothing about the account area. It also only sees cookies set in Set-Cookie response headers - cookies written later by JavaScript, including most analytics and consent cookies, are invisible to a passive check because they do not exist until the page runs.

For a cookie you are designing rather than auditing, use Secure Cookie Builder. For the wider header picture, run the Website Security Audit.

Frequently asked questions

References

• RFC 6265: HTTP State Management Mechanism
• MDN: Set-Cookie
• OWASP Session Management Cheat Sheet

Related tools