Inspect attributes that page JavaScript cannot normally read
A session cookie can be protected by several independent attributes. Secure restricts sending to secure transport, HttpOnly prevents ordinary script access, SameSite affects cross-site sending, and Domain plus Path define where the cookie applies. These settings solve different problems. A cookie can have one useful attribute while still having an overly broad scope or a missing protection.
This auditor reviews Set-Cookie response headers that you paste. It cannot inspect every cookie in your browser, and it deliberately does not pretend that document.cookie can reveal HttpOnly cookies. Copy the response headers from the browser’s Network panel and redact values if possible. The report keeps cookie names and attributes while excluding the cookie values.
Collect the right header without losing information
Open the request that creates or refreshes the cookie and inspect its response headers. Copy each Set-Cookie line separately. Do not use the Cookie request header as a substitute: it normally contains names and values sent back to a server, without the attributes that were used when the cookies were set.
One line should describe one cookie. Combining multiple Set-Cookie headers with commas can be ambiguous because expiry dates contain commas. This tool splits records by line and attributes by semicolon. If your developer tools combine the display, expand or copy the individual header values before running the audit.
Use test sessions when possible. Even though the analysis is local, a live session value is sensitive material that can accidentally enter a screenshot or clipboard history. Replacing the value after the first equals sign with a harmless sample normally preserves the attributes needed for this check. Keep the cookie name when testing prefix requirements because the name is part of those rules.
The Overview tab explains the findings. Measured data lets you search individual fields and values, while JSON report shows the complete export. Export JSON to retain a baseline, or print the findings for your own records. Review the report before sharing it: browser characteristics, token claims, and file names can reveal information about your setup.
Review transport, script access and cross-site behaviour
Secure is appropriate for cookies that should travel only over HTTPS. HttpOnly prevents ordinary JavaScript from reading the cookie through document.cookie, which reduces one consequence of script injection. It does not prevent all cross-site scripting impact: malicious script may still issue authenticated requests from the compromised page.
SameSite can be Strict, Lax or None. The right choice depends on navigation and integration requirements. Strict can disrupt expected cross-site entry flows, while Lax allows some cross-site top-level navigation cases. None is used when cross-site sending is necessary and requires Secure in modern browsers. The auditor highlights missing or unrecognised values and the invalid None-without-Secure combination.
An explicit policy is easier to reason about than relying on defaults that can vary by browser and context. Even with SameSite, sensitive state-changing actions should use appropriate request validation and anti-CSRF design. A cookie attribute is one layer, not a complete application authorisation strategy.
Use scope and prefixes intentionally
Omitting Domain normally creates a host-only cookie. Adding Domain broadens the matching scope to applicable subdomains, which can be useful but increases the number of services that participate in the cookie’s trust boundary. The auditor flags a Domain attribute for review instead of assuming all shared-domain cookies are mistakes.
Cookie name prefixes provide additional rules that supporting browsers can enforce. A __Secure- cookie requires Secure and a secure origin. A __Host- cookie additionally requires Path=/ and no Domain attribute. This tool can check the pasted attributes, but it cannot establish the response’s original transport context from the text alone.
The Path attribute controls when a browser includes a cookie in requests; it is not a strong isolation boundary against hostile code on the same origin. Partitioned cookies introduce another storage dimension for supported use cases and also require Secure. Browser support and third-party cookie policies can affect behaviour beyond what a single header line reveals.
After changing attributes, clear or expire old cookies with the correct scope and test the complete login lifecycle. Two cookies with the same name but different paths or domains can coexist. A successful new header does not guarantee that an older, broader cookie was removed.
Check deletion headers as carefully as creation headers. To expire an existing cookie, the replacement generally needs to target the same name, domain and path. An expiry instruction aimed at a different scope can leave the original session cookie in place while appearing successful in a log.
Attributes and focused checks
| Attribute or prefix | Audit interpretation |
|---|---|
| Secure | Missing transport restriction is highlighted. |
| HttpOnly | Missing script-read restriction is highlighted; script-readable preferences may be intentional. |
| SameSite=None | Secure is required by modern browser behaviour. |
| __Host- | Requires Secure, Path=/ and no Domain attribute. |
| Partitioned | Secure is required; full browser storage policy is not simulated. |
Strengths and limitations
What this is useful for
The checker works with the actual response representation and can review HttpOnly attributes without needing privileged browser access. It avoids echoing cookie values into the exported report. Prefix and SameSite checks help find configuration errors that a simple “cookies enabled” test would miss.
What to keep in mind
Pasted text cannot reproduce the complete browser context. The audit does not see existing cookies, confirm secure-origin delivery, validate expiry semantics or test application CSRF defences. Some script-readable cookies are intentional, so missing HttpOnly requires a contextual decision rather than automatic rejection.
Common questions
Why can the tool not scan all my cookies automatically?
Ordinary webpages cannot read another origin’s cookies, and HttpOnly cookies are intentionally hidden from page scripts. A claim to inventory them from this page would be misleading. Pasting response headers gives the tool the necessary attributes without requiring a browser extension or access to your accounts.
Should every cookie use HttpOnly?
Authentication and sensitive session cookies usually benefit from HttpOnly. Some non-sensitive preferences or application features intentionally require script access. Evaluate the purpose of each cookie and avoid putting secrets in script-readable storage merely because a library expects convenient access.
Are the headers sent to a server?
No. The audit parses the pasted lines in the tab. The generated report includes cookie names and attributes, not their values. Clipboard history, browser extensions and screenshots are outside the application’s control, so redacting live session values before pasting remains sensible practice.
Does SameSite replace CSRF protection?
It can substantially reduce some cross-site request risks, but it is not a complete replacement for application-level protections. Same-site subdomain threats, navigation behaviour, browser compatibility and business logic still matter. Use appropriate anti-CSRF tokens, origin checks and authorisation for sensitive operations.