0
Not analyzed
Run the checker to evaluate cookie security.
Cookie Security Checker
Inspect Secure, HttpOnly, SameSite, Domain, Path and expiration settings across one or more Set-Cookie headers.
Paste one or more Set-Cookie values, or enter a public website URL to inspect cookies returned by the server.
🍪
Cookies Found
0
Set-Cookie headers
🔒
Secure
0
HTTPS-only cookies
🙈
HttpOnly
0
blocked from JavaScript
🧭
SameSite Set
0
cross-site policy defined
⚠️
High-Risk Cookies
0
important weaknesses
✓
Strong Cookies
0
recommended protections
⏳
Persistent
0
Expires or Max-Age set
🌍
Broad Domain
0
shared across subdomains
🔎 Security Findings
💡 Recommended Improvements
🧾 Normalized Cookie Headers
🌐 Source Information
HOW IT WORKS
Manual Analysis in Your Browser, Live Checks From Our Server
Pasting Set-Cookie header values and analyzing them for Secure, HttpOnly, SameSite, prefix and expiration rules happens entirely in your browser - nothing is sent anywhere. Checking a live website is different: browsers deliberately hide the Set-Cookie response header from cross-origin JavaScript, so our .NET backend fetches the page instead and reads the raw Set-Cookie headers directly off the HTTP response (never a comma-merged approximation). The same SSRF protections used across our security tools apply here too - private, loopback, link-local and cloud-metadata addresses are always rejected, and every redirect hop is re-validated before being followed. The backend never stores or logs the cookie values it reads, and only response headers are fetched - the page body is never downloaded.
Related tools: Security Headers Checker · CSP Checker · CORS Checker
Cookie Security Checker FAQ
Why does SameSite=None without Secure matter?
Modern browsers reject cookies marked SameSite=None unless they also have the Secure flag, so this combination usually means the cookie will silently fail to be set at all - a functional bug as much as a security one.
What do the __Host- and __Secure- prefixes do?
These are browser-enforced naming conventions: a __Host- cookie must have Secure, no Domain attribute, and Path=/, while a __Secure- cookie must have Secure set. Browsers reject a Set-Cookie header that uses the prefix without meeting its rules.
Can I check an internal or private site's cookies?
No. Hostnames that resolve to localhost, private IP ranges, link-local addresses or cloud metadata endpoints are rejected before any request is made, and each redirect hop is re-validated the same way.
Does the backend store the cookies it reads?
No. Cookie values pass straight through the response and are never written to logs or storage - only the exception message is logged if a fetch fails, never response content.
Why does the tool disable normal cookie handling when fetching a site?
By default, .NET's HTTP client would quietly absorb Set-Cookie headers into its own cookie store instead of surfacing them - and would carry cookies between requests. This tool disables that entirely so each check is stateless and the raw headers are always returned.