Website Security
Cookie Security Scanner
Parses your Set-Cookie headers and checks each cookie's flags against session-security best practice.
What is Cookie Security Scanner?
Cookies often hold the keys to a user's session, and a handful of flags on each cookie decide how well that session is protected. HttpOnly hides the cookie from JavaScript, Secure stops it being sent over plain HTTP, and SameSite controls whether it rides along on cross-site requests. Set correctly, these flags neutralize entire attack classes; left off, a session cookie is far easier to steal or abuse.
What Nandix checks
- HttpOnly and Secure flags
- SameSite policy (missing, or None without Secure)
- Overly broad Domain scope and root Path
- __Secure-/__Host- prefix violations
- Excessive or persistent expiry, and technology-fingerprinting cookie names
Probes
11 checks
How it detects
Passive. It parses the Set-Cookie headers returned by the target and evaluates each cookie's attributes — no cookies are forged or replayed. Session cookies missing HttpOnly or Secure are the most severe findings; weaker issues (long expiry, fingerprintable names) are informational.
Why it's dangerous
A session cookie without HttpOnly can be read by any injected JavaScript, so a single XSS flaw turns into full account takeover — the attacker simply steals the session. Without Secure, the cookie leaks over any accidental HTTP request, readable by anyone on the network path. Without SameSite, the cookie is sent on cross-site requests, opening the door to CSRF, where a malicious page performs actions as the logged-in victim. These are among the most common real-world paths to account compromise.
Example finding
The session cookie is readable by JavaScript — any XSS vulnerability becomes a full session-hijack and account takeover.
How to fix it
Set the protective flags on every session and auth cookie. HttpOnly on anything holding a session — it should never be readable by JavaScript. Secure always, so the cookie is only ever sent over HTTPS. SameSite=Lax as a sane default (Strict for the most sensitive), and if you must use SameSite=None, it must also be Secure. Scope tightly — avoid an over-broad Domain, and prefer the __Host- prefix for host-locked cookies.
js
res.cookie('session', token, {
httpOnly: true, // hidden from JS
secure: true, // HTTPS only
sameSite: 'lax', // blocks most CSRF
path: '/',
maxAge: 1000 * 60 * 60 * 2,
});Severities & standards
Severities
CRITICAL · HIGH · MEDIUM · LOW
References
Frequently asked questions
What's the difference between SameSite Lax and Strict?
Strict never sends the cookie on any cross-site navigation (so a link from another site logs the user out until they navigate). Lax sends it on top-level navigations but not on embedded/background requests — a good balance for most apps.
Which flag prevents session theft via XSS?
HttpOnly. It stops JavaScript from reading the cookie, so even if an attacker injects a script, they can't lift the session token.
Do these flags replace CSRF tokens?
SameSite reduces CSRF risk significantly but isn't a complete replacement for anti-CSRF tokens on sensitive actions. Use both.
See how every check runs on the methodology page, or browse all scanners.
Scan your site for this →Free cookie security scanner. Nandix inspects your Set-Cookie headers for missing HttpOnly, Secure, and SameSite flags that expose session cookies to theft and cross-site attacks.