Cookie Security Checker

How it works

Session and preference cookies are high-value if they leak. We fetch your public URL and inspect Set-Cookie flags for Secure, HttpOnly, and SameSite. Missing Secure allows transmission over HTTP; missing HttpOnly exposes cookies to XSS; missing SameSite weakens CSRF defenses.\n\nMarketing homepages often set no cookies - we say so and suggest trying an app or login URL. Multiple Set-Cookie headers can be imperfectly joined by intermediaries, so treat the parse as a teaser, not a forensic cookie jar dump. We do not log in, complete OAuth, or inspect cookie values - only flags on what the response sets.\n\nTighten flags in your framework session config or CDN, then re-check. Pair with the headers and CORS checkers: cookie theft usually needs another bug. When you are ready for depth, AtRisk Starter unlocks fuller findings and fix prompts.\n\nThis is not a penetration test or authenticated session review - public response headers only. Framework defaults vary: some set Secure in production only, others forget SameSite on custom cookies. Review analytics and A/B cookies too - third-party scripts often set weak flags you still own on your domain. Prefer host-only cookies for sessions, short lifetimes, and rotating session IDs after login. Re-test after auth changes. This teaser will not see cookies set only after a POST login; for those, rely on a full product scan and manual review.

This is a free teaser check - not a penetration test, vulnerability assessment, or compliance audit. AtRisk full scans go deeper across more detectors and unlock fix prompts on Starter.