Cookie Security Flags: Secure, HttpOnly, SameSite
Every cookie your application sets carries security-relevant attributes. Missing a single flag can expose session tokens to theft via XSS (no HttpOnly), network interception (no Secure), or cross-site request forgery (no SameSite). Checking these flags is one of the fastest ways to assess a site's security posture.
Try it now
Cookie Analyzer
Runs in your browser, nothing leaves your device.
HttpOnly prevents JavaScript from reading the cookie, blocking XSS-based session theft. Secure ensures the cookie only travels over HTTPS, preventing network sniffing. SameSite controls cross-origin cookie sending: Strict blocks all cross-site sends, Lax allows top-level navigations (GET requests), None allows everything but requires Secure.
Session cookies without HttpOnly are the most dangerous misconfiguration. One XSS vulnerability gives the attacker direct access to session tokens via document.cookie. Cookies set on overly broad domains (.example.com instead of app.example.com) can be read by any subdomain. Short or missing expiry on session cookies means stolen tokens remain valid indefinitely.
Examples
Insecure session cookie
Set-Cookie: session=abc123; Path=/
Missing: Secure, HttpOnly, SameSite. Vulnerable to XSS theft and CSRF.
Properly secured cookie
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
All critical flags present. Protected against common attacks.
Security context
Cookie flags are the last line of defense for session tokens. Even if your application has zero other vulnerabilities, a missing HttpOnly flag means a future XSS bug instantly becomes a session hijacking vector.
Frequently asked
Lax is the practical choice for most session cookies. Strict breaks legitimate flows like clicking a link to your site from an email (the session cookie won't be sent). Lax sends cookies on top-level GET navigations but blocks them on cross-site POST requests, which stops most CSRF attacks.
Related techniques
Content Security Policy (CSP) Analysis
How to analyze and audit Content-Security-Policy headers. Detect unsafe-inline, unsafe-eval, wildcard sources, and other misconfigurations that enable XSS.
HTTP Security Headers Checklist
Review HTTP response headers for security misconfigurations. Check for missing HSTS, X-Content-Type-Options, X-Frame-Options, and information leaks in Server headers.
CORS Misconfigurations and Security Risks
Detect dangerous CORS configurations: wildcard origins with credentials, reflected origins, null origin attacks, and overly permissive access-control headers.