Tools
Cookie scanner
A cookie scanner records every cookie a site sets in real Set-Cookie response headers during a crawl, then reports each one's scope, lifetime, size and security attributes. The inventory is the part that matters: a cookie policy can only describe cookies someone knows about, and on most sites the list contains entries nobody remembers adding — left behind by a tag that was removed, or set by a script three dependencies deep.
What the inventory records for each cookie
Scope: whether the cookie is host-only or shared with every subdomain, and whether its path is the whole site or a narrower branch.
Lifetime: session or persistent, and for persistent ones the expiry that results after the precedence rule is applied — Max-Age wins over Expires when both are present.
Size: the approximate byte size against the 4 KB per-cookie browser limit, which matters because cookies are re-sent on every request to the domain.
Security attributes: Secure, HttpOnly and SameSite, evaluated against what the cookie appears to be for.
Origin: whether the cookie's domain is yours or belongs to another registrable domain, which is the line between a first-party and a third-party cookie.
Why scope is the finding people underestimate
A cookie set on the registrable domain rather than the host is sent to every subdomain under it — including the ones running something else entirely.
That is how a session cookie for the main application ends up being transmitted to a marketing subdomain, a status page or a third-party service given a CNAME.
The fix costs nothing and is invisible to users: set the cookie host-only unless a subdomain genuinely needs it, and narrow the path where a branch of the site is the only consumer.
The same reasoning applies to size in a different direction. A large cookie on a domain-wide scope is re-sent with every request to every subdomain, which is a request-size tax paid on every page load.
What a clean result looks like
A list you can account for: every cookie has a purpose you can name and a lifetime that matches it.
Session-like and authentication cookies carrying Secure and HttpOnly, with SameSite at Lax or stricter.
Persistent cookies with lifetimes that are deliberate rather than defaults — and measurement cookies inside thirteen months.
Cookies scoped to the host that needs them, with domain-wide scope used only where a subdomain really consumes them.
No cookie approaching the 4 KB limit, because a payload that large belongs on the server with an identifier in the cookie.
The coverage statement, which is part of the result
This inventory is built from HTTP response headers. Cookies written by JavaScript after the page loads are not in it, and the report says so rather than presenting the HTTP list as complete.
That distinction matters more than it sounds, because analytics and advertising tags frequently set their cookies from script rather than from a header.
So a clean HTTP inventory is a clean HTTP inventory. Finishing the picture needs a browser session and the storage panel of its developer tools.
An audit that did not state this would be handing you false confidence, which on a consent question is worse than no audit.
What VeriFixScan uses
`cookies.inventory` builds the list from real Set-Cookie headers. `cookies.count` totals it and splits session from persistent. `cookies.persistence` separates the two. `cookies.size` measures each against the 4 KB limit.
`cookies.domain_path` reports the scope of each cookie. `cookies.javascript` is the coverage statement: it says which cookies this scan can and cannot see.
The attribute checks — Secure, HttpOnly, SameSite — run over the same inventory and are reported against their own problem pages.
Frequently asked questions
- Why does your list have fewer cookies than my browser shows?
- Because the browser shows everything, including cookies written by scripts after the page loaded. This inventory is built from response headers, which is a subset — and the report states that rather than implying the list is complete.
- Is a large number of cookies a defect?
- Only when it is unjustified. The count itself is reported as an observation. What makes it a finding is a list where several entries have no owner, which usually means unmanaged third-party tags.
- Does a cookie scoped to my whole domain break anything?
- Not functionally — it is sent to more places than needed. That is a disclosure question rather than a broken feature, and it becomes one that matters when a subdomain runs software you do not control.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website