Learn

Secure cookies: Secure, HttpOnly, SameSite reference

Three attributes stand between your session cookie and an attacker. Get Secure, HttpOnly, and SameSite right, and most cookie-stealing tricks die at the door.

What it is

Cookie security means setting the right attributes on session and auth cookies: Secure (only over HTTPS), HttpOnly (not readable by JavaScript), and SameSite (limits cross-site sending). Monitoring checks that your Set-Cookie headers include these attributes.

Why it matters

Cookies without Secure can be sent over HTTP and intercepted. Without HttpOnly, XSS can steal session tokens. Without SameSite, cross-site requests can carry the cookie (CSRF risk). Monitoring catches cookies that are missing these attributes so you can fix them before an incident.

How Barrion checks it

Barrion inspects Set-Cookie response headers from your app. We report cookies that lack Secure, HttpOnly, or SameSite (or use SameSite=None without Secure). Each finding includes which attribute is missing and how to fix it. Scans are passive and do not modify cookies.

Configuration examples

Node.js (Express): hardened session cookie
res.cookie('session', token, { secure: true, httpOnly: true, sameSite: 'lax' })

Verify it

curl -sI https://example.com | grep -i set-cookie
Run this check →Fix guide

Related

FAQ

Common questions.

HttpOnly, Secure, SameSite, what is the order of importance?
For a session cookie, HttpOnly is the highest-leverage flag because it stops XSS from reading the token. Secure comes next so the cookie cannot leak over a downgraded HTTP request, and SameSite (Lax at minimum) closes most CSRF paths.
Is SameSite=Strict ever wrong?
Yes. Strict cookies are not sent on the first cross-site navigation, so any flow where a user lands on your domain from an external link (SSO callback, password reset email, payment redirect) will look logged-out until they navigate again. Use Lax for the main session and reserve Strict for sensitive sub-cookies like CSRF tokens.
Do cookies need a Domain attribute?
Usually not. Omitting Domain scopes the cookie to the exact host that set it, which is the safest default. Set Domain only when you genuinely need to share state across subdomains, and pair it with __Host- prefixed names or split cookies so a compromised subdomain cannot steal the parent session.
What do the __Host- and __Secure- prefixes do?
__Secure- requires the Secure flag, and __Host- additionally requires no Domain attribute and Path=/. Browsers reject any Set-Cookie that violates the prefix contract, which gives you compile-time-style guarantees that a session cookie cannot be downgraded or scoped to a sibling subdomain.