Securing cookies: HttpOnly, Secure and SameSite
Three cookie attributes stop most session-theft and cross-site request attacks. Learn what each does and how to set them.
Cookies that carry a session are a prime target: steal one and you're logged in as the victim. Three attributes on the Set-Cookie header remove most of that risk, and they're trivial to add.
HttpOnly
HttpOnly hides the cookie from JavaScript (document.cookie). If an attacker manages to inject script, they still can't read a HttpOnly session cookie — turning many XSS bugs from account-takeover into something far less severe.
Secure
Secure means the cookie is only ever sent over HTTPS, so it can't leak over an accidental plain-http request.
SameSite
SameSite controls whether the cookie is sent on cross-site requests. Lax (a good default) sends it on top-level navigations but not on cross-site sub-requests, which blocks most cross-site request forgery (CSRF). Strict is tighter; None (required for genuine cross-site use) must be paired with Secure.
Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax; Path=/How to fix it
- Add HttpOnly and Secure to every session or auth cookie.
- Set SameSite=Lax unless you have a specific cross-site need (then None; Secure).
- Scope cookies with Path and, where possible, a short lifetime.
- Re-scan to confirm the flags are present on the Set-Cookie response.
Glossary
- HttpOnly
- A cookie flag that prevents JavaScript from reading the cookie, limiting XSS impact.
- SameSite
- A cookie flag controlling whether the cookie is sent on cross-site requests; a key CSRF defence.
- CSRF
- Cross-site request forgery: tricking a logged-in user's browser into making an unwanted state-changing request.