Cookie security flags control how browsers handle sensitive cookies. Secure restricts them to HTTPS, HttpOnly hides them from JavaScript to blunt XSS, and SameSite limits cross-site sending to defend against CSRF. Session cookies should almost always set all three.
A session cookie is as valuable as a password. The Secure, HttpOnly and SameSite attributes are the standard, low-effort defences that stop cookies leaking over HTTP, being stolen by injected scripts, or being sent along with cross-site forgery attacks.
Check your website
See how your site handles cookie security: secure, httponly and samesite explained — free, no account needed.
For business owners
If a session cookie is stolen, an attacker can impersonate a logged-in user without ever knowing their password. Setting the right cookie flags is a near-zero-cost change that dramatically reduces the risk of account takeover — exactly the kind of quiet, high-impact hardening that protects both customers and your reputation.
How it works (technical)
Set these attributes on sensitive cookies:
- Secure — the cookie is only sent over HTTPS, preventing exposure on plain HTTP.
- HttpOnly — the cookie is inaccessible to
document.cookie, limiting theft via cross-site scripting. - SameSite —
Strict,LaxorNonecontrols whether the cookie is sent on cross-site requests.Laxis a sensible default;NonerequiresSecure.
Example: Set-Cookie: session=abc; Secure; HttpOnly; SameSite=Lax; Path=/. Consider the __Host- prefix for extra hardening and keep cookie lifetimes short.
Real-world example
An app stored its session cookie without HttpOnly. A single reflected-XSS bug let an attacker read document.cookie and hijack sessions. Adding HttpOnly, Secure and SameSite=Lax meant that even when a later XSS bug appeared, the session cookie could not be exfiltrated the same way.
Why it matters
Cookie flags are a primary defence for session integrity against XSS and CSRF. Scanners check that sensitive cookies set Secure, HttpOnly and an appropriate SameSite value.
How to fix it
Add
Secureto every cookie so it is never sent over plain HTTP.Add
HttpOnlyto session and auth cookies so scripts cannot read them.Set
SameSite=Lax(orStrictwhere UX allows) to limit cross-site sending.Use
SameSite=None; Secureonly when a cookie genuinely must cross sites.Keep session lifetimes short and consider the
__Host-prefix.
Best practices
Default sensitive cookies to Secure + HttpOnly + SameSite=Lax.
Reserve SameSite=None for genuine cross-site needs, always with Secure.
Combine cookie flags with CSRF tokens for state-changing requests.
Common mistakes
Leaving session cookies readable by JavaScript (no HttpOnly).
Omitting Secure, allowing cookies to leak over HTTP.
Using SameSite=None without Secure, which browsers now reject.
Frequently asked questions
Does HttpOnly stop all cookie theft?
It stops JavaScript from reading the cookie, which blunts many XSS-based thefts, but it is one layer. Combine it with Secure, SameSite, CSP and short sessions.
Which SameSite value should I use?
Lax is a good default that protects against most CSRF while keeping normal navigation working. Use Strict for the most sensitive cookies, and None (with Secure) only for genuine cross-site scenarios.
Put this into practice
See how your site scores with Plexa Trust — start with a free scan, then unlock the complete audit on Pro.
Scan your website free