Cookie Security: HttpOnly, Secure, SameSite
Three cookie attributes do most of the heavy lifting for session security: HttpOnly, Secure, and SameSite. Set them correctly and a session cookie resists theft by scripts, exposure over plaintext, and abuse by other sites. Leave them off and the same cookie becomes an easy prize. They are one line of configuration with outsized impact.
What does each attribute defend against?#
Each closes a distinct attack:
| Attribute | Defends against | Setting |
|---|---|---|
HttpOnly | Cookie theft via XSS | Always, on session cookies |
Secure | Interception over plain HTTP | Always |
SameSite | CSRF | Lax or Strict |
A well-configured session cookie looks like:
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Lax; Path=/How do the attributes work together?#
They cover different threats, so you use them in combination. HttpOnly removes the classic
document.cookie theft path — though note that XSS can still act as the user even without
reading the cookie, so it narrows rather than eliminates the risk. Secure ensures the cookie
never rides over unencrypted HTTP. SameSite stops other sites from silently causing
authenticated requests.
These attributes are the foundation of session management. More at the Web Security hub.
Frequently asked questions#
What does the HttpOnly cookie flag do?
HttpOnly tells the browser not to expose the cookie to JavaScript via document.cookie. It means a cross-site scripting attack cannot directly steal the cookie’s value, so session cookies marked HttpOnly resist the classic theft technique. The cookie still travels normally on requests; it is just invisible to page scripts.
What does SameSite do for cookies?
SameSite controls whether a cookie is sent on cross-site requests. Strict withholds it on all cross-site navigation; Lax (the modern default) sends it only on top-level navigations; None sends it always but requires Secure. It is a primary defense against cross-site request forgery.