Secure Cookie Tester

Secure cookie tester online for Secure, HttpOnly, and SameSite checks

A “secure cookie tester” is a quick way to verify whether a site is setting cookies with the security attributes you expect: Secure, HttpOnly, and SameSite. Misconfigured cookies are a common root cause behind session theft (XSS-assisted), CSRF exposure, and accidental cross-subdomain leakage.

This tool focuses on the cookie attributes you can validate from HTTP traffic. It does not “prove” an app is secure, but it does help you catch configuration gaps early.

Key Features

• Checks presence of key flags: Secure, HttpOnly, and SameSite
• Highlights scope attributes that often cause leakage: Domain and Path
• Surfaces expiry and persistence signals (session vs persistent cookies)
• Useful for triage during deployments, CDN changes, and auth refactors
• Designed for repeat testing (run before and after you ship changes)

Use Cases

• Validate that session cookies are marked Secure and HttpOnly after enabling HTTPS everywhere.
• Confirm SameSite behavior after a login or OAuth callback change.
• Detect “too-wide” Domain scoping (e.g., .example.com when only app.example.com should receive the cookie).
• Compare staging vs production cookie settings during a rollout.
• Pair cookie checks with transport hardening checks using HSTS Tester.

How To Use

1. Open the page you want to test (login page, post-login dashboard, checkout, etc.).
2. Run the tester against the target URL and trigger the action that sets cookies (sign in, set preference, start trial).
3. Review each Set-Cookie result and confirm:

• Secure is present for any cookie that should never traverse plaintext HTTP.
• HttpOnly is present for session/auth cookies so JS can’t read them.
• SameSite is set to the level that matches your flows (see below).

1. If you see a missing attribute, fix it server-side, then re-run the test and confirm the response headers changed.

Safety note: don’t paste secrets, raw session tokens, or private production cookies into untrusted environments. Use test accounts or sanitized traffic when possible.

How It Works

Under the hood, cookie analysis is based on HTTP response headers:

• The server sends one or more Set-Cookie headers.
• Each header contains a cookie name/value plus attributes such as Secure, HttpOnly, SameSite, Domain, Path, and Max-Age / Expires.
• The tool parses those attributes and flags common risky patterns.

Practical interpretation:

• Secure missing: cookie can be sent over HTTP if a user ever hits a plaintext endpoint (or if an attacker can force a downgrade).
• HttpOnly missing: any XSS issue becomes far more damaging because JS can read the cookie value.
• SameSite missing/weak: cross-site requests may include cookies, increasing CSRF risk.
• Domain too broad: a subdomain compromise can potentially read/overwrite cookies intended for a different app.

Manual sanity check (fast): open browser dev tools → Network → select the response → confirm the exact Set-Cookie attributes match what the tester reports. If your test results differ, review proxies/CDNs that may be rewriting headers; an SSL Checker can help validate that the target is consistently served via HTTPS.

http

Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
Set-Cookie: prefs=darkmode; Path=/; Max-Age=2592000; SameSite=Lax

Examples

• Secure cookie tester free: quick validation during a release when you changed cookie middleware defaults.
• Secure cookie attribute: verify Domain and Path don’t over-scope the cookie.
• Cookie scanner: test login, then test a privileged action to ensure no new cookies are introduced without flags.
• Secure cookie tester app/software: use the output as a checklist for your team’s “auth hardening” acceptance criteria.

Edge Cases & Troubleshooting

• SameSite=None without Secure: modern browsers reject this combination; your cookie may silently fail to set.
• Cross-site login flows: SSO and third-party redirects sometimes need SameSite=None; Secure. Validate carefully and limit which cookies are impacted.
• Multiple cookies with same name: differing Path or Domain attributes can create confusing behavior. Prefer unique names or consistent scoping.
• Subdomain environments: staging domains (staging.example.com) can hide Domain mistakes that break on production apex domains.
• Clock and expiry issues: Expires dates in the past or extreme Max-Age values can cause “random” logouts.

Common mismatch checklist when results look wrong:

• You tested a cached response that didn’t include Set-Cookie.
• A reverse proxy stripped or rewrote cookie attributes.
• You tested the wrong path (cookie is only set after a redirect or API call).
• A SPA sets tokens in storage (not cookies), so you’re looking in the wrong place.

FAQ

How to check cookie secure flag in Chrome?

Open DevTools → Application → Cookies, select your site, and inspect the “Secure” column for each cookie. You can also inspect the Set-Cookie header in the Network tab to see what the server actually sets.

What should SameSite be for session cookies?

For most traditional web apps, SameSite=Lax is a sane default because it mitigates many CSRF cases without breaking normal navigation. If you have cross-site embedding or complex SSO flows, you may need SameSite=None; Secure for specific cookies—treat that as an exception, not a default.

Does HttpOnly prevent XSS?

No. HttpOnly reduces the impact of XSS by preventing JavaScript from reading cookie values. You still need to fix XSS vulnerabilities and use CSP and output encoding.

Is Secure enough if I force HTTPS?

Secure is necessary but not sufficient. You still need correct Domain/Path scoping, sane expiry, and a CSRF strategy (SameSite + tokens where appropriate).

Next Steps / Related Workflows

• After you fix cookie flags, validate broader security headers (CSP, frame protections, referrer policies) and document a public contact point using security.txt generator.
• Add automated tests in your CI to assert Set-Cookie attributes for critical endpoints.
• If your app uses multiple subdomains, standardize cookie scope rules and explicitly document them for future releases.