Cookie Security Analyzer
Analyze cookies returned by any URL for security attributes. Checks HttpOnly, Secure, SameSite (Strict/Lax/None), Domain scope, expiry, and flags insecure configurations. Get a per-cookie security score and recommendations.
How to Use Cookie Security Analyzer
- 1Enter a URL to analyze its cookies.
- 2The tool fetches the URL and collects all Set-Cookie response headers.
- 3Each cookie is analyzed for HttpOnly, Secure, SameSite, and other security attributes.
- 4Issues and recommendations are shown for each insecure cookie.
Zenovay
Privacy-first analytics for your website
Understand your visitors without invasive tracking. GDPR compliant, lightweight, and powerful.
Related Tools
Password GeneratorGenerate strong, random passwords with customizable length, characters, and complexity.
Password Strength CheckerCheck how strong your password is. Get an estimated crack time and improvement suggestions.
HMAC GeneratorGenerate HMAC signatures using SHA-256, SHA-384, or SHA-512 with the Web Crypto API.
AES Encryption/DecryptionEncrypt and decrypt text using AES-GCM with PBKDF2 key derivation. Runs entirely in your browser.
Frequently Asked Questions
What security attributes should every cookie have?▾
Every session or authentication cookie should have: (1) HttpOnly — prevents JavaScript access, blocking XSS cookie theft; (2) Secure — ensures the cookie is only sent over HTTPS, preventing interception; (3) SameSite=Strict or Lax — prevents CSRF attacks by restricting when cookies are sent cross-site. For non-sensitive cookies (analytics, preferences), relaxed settings may be acceptable, but security-critical cookies (session IDs, auth tokens) should always have all three.
What is the SameSite attribute and which value should I use?▾
SameSite controls when a cookie is sent with cross-site requests. Strict: only sent for same-site requests (most secure, but may break OAuth flows and links from emails). Lax (default in modern browsers): sent for top-level navigation but not cross-site API requests. None: sent for all cross-site requests — requires Secure flag. Use Strict for auth/session cookies. Lax for most others. None only for third-party cookies that must work cross-site (e.g., embedded widgets, SSO).
What is the difference between session cookies and persistent cookies?▾
Session cookies have no Expires or Max-Age attribute — they are deleted when the browser session ends (user closes the browser tab/window). Persistent cookies have an Expires date or Max-Age value and survive browser restarts. For authentication, session cookies are more secure (shorter window of exposure), but can be inconvenient for "remember me" features. Long-lived persistent cookies are higher risk — if stolen, they remain valid longer.
Why might third-party cookies be blocked?▾
Browsers are phasing out third-party cookies (cookies set with a Domain attribute different from the page's domain) for privacy reasons. Chrome is moving away from third-party cookies, Safari and Firefox already block them by default. If your cookies have a Domain set to a different domain, they will be blocked for cross-site requests. Modern authentication patterns use same-site alternatives like OAuth redirect flows, token-based auth, or browser partitioned storage.
Why does this tool only show cookies from the initial response?▾
The analyzer fetches the URL and inspects Set-Cookie headers in the HTTP response. Cookies set by JavaScript (document.cookie) after page load are not visible, as the tool only sees server-side cookies. Additionally, some applications only set cookies after login or specific actions — testing a login page URL may show different cookies than the homepage. For comprehensive cookie auditing, use browser DevTools and log all Set-Cookie headers across your entire user flow.