Secure, HttpOnly, and SameSite cookie flags
Session cookies are a prime target. Three attributes — Secure, HttpOnly, and SameSite — determine whether an attacker can steal or misuse them. Missing flags lead directly to session hijacking and CSRF.
What it is
Secure sends the cookie only over HTTPS. HttpOnly hides it from JavaScript (document.cookie). SameSite controls whether it's sent on cross-site requests.
Together they shrink the attack surface: an attacker can't read the cookie via injected script, can't sniff it over HTTP, and can't ride it from another site.
Why it matters
Without HttpOnly, any XSS bug can read the session cookie and hand the attacker a logged-in session. Without Secure, the cookie leaks over any plain-HTTP request.
Without SameSite, the browser attaches the cookie to cross-site requests, which is the mechanism CSRF attacks depend on.
How to fix it
Most frameworks expose these as options when you set the cookie.
res.cookie("session", token, {
secure: true,
httpOnly: true,
sameSite: "lax", // or "strict" for maximum protection
path: "/",
});Naming a cookie __Host- forces the browser to require Secure, Path=/, and no Domain — a strong, self-enforcing baseline for session cookies.
If you genuinely need cross-site cookies, SameSite=None is only honored when Secure is also set; otherwise modern browsers drop the cookie.
FAQ
Lax or Strict for SameSite?
Lax is a safe default that still allows top-level navigations. Strict is tighter but can break flows where users arrive from external links while expecting to be logged in.
Do these flags stop XSS?
HttpOnly limits the damage of XSS by hiding the cookie, but it doesn't prevent XSS. Pair it with a strong Content-Security-Policy.
Is your app affected?
AppSafe checks for this and dozens of other issues in one free scan.
Scan my app free