Securing Cookies with HttpOnly, Secure, and SameSite

Why it exists

By default, cookies are insecure. They can be read by client-side scripts, sent over unencrypted HTTP, and attached to requests initiated by other websites. This exposes sensitive data like session IDs to Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) attacks. Secure cookie attributes were created to give developers control to mitigate these specific vulnerabilities.

The mental model

Treat a standard cookie like a postcard: anyone who intercepts it can read it, and it can be sent from anywhere. Secure attributes are like putting that postcard in a locked, armored box that can only be delivered to a specific address under specific conditions. HttpOnly is the lock, Secure is the armored transport, and SameSite is the strict delivery instruction.

How it works

These are flags set in the Set-Cookie HTTP response header from the server. There are three main attributes for security. First, HttpOnly: This tells the browser to prevent client-side scripts from accessing the cookie. It's a critical defense against XSS attacks where an attacker injects script to steal session cookies. Second, Secure: This ensures the browser only sends the cookie with requests made over an encrypted HTTPS connection. It prevents attackers from sniffing the cookie data on an insecure network. Third, SameSite: This attribute controls whether a cookie is sent with cross-site requests, providing CSRF protection. Strict prevents the cookie from being sent on any cross-site request. Lax is a good default, allowing cookies on top-level navigation (e.g., clicking a link to your site from another). None allows cross-site usage but requires the Secure attribute.

When to use it

Always use these attributes for any cookie containing sensitive information, especially session identifiers. A good default for session cookies is HttpOnly, Secure, and SameSite=Lax. This provides a strong security baseline with good usability. Use SameSite=Strict for actions on highly sensitive pages, like changing a password.

When not to use it

Avoid these attributes only in specific scenarios. Don't use HttpOnly if your own client-side JavaScript genuinely needs to read a cookie's value. Avoid Secure only during local development without HTTPS. Use SameSite=None only for cookies explicitly designed for cross-site contexts, like those used by some third-party authentication or ad-tech services.

One canonical example

In an Express.js application, setting a secure session cookie looks like this: res.cookie('sessionId', 'abc123xyz', { httpOnly: true, secure: true, sameSite: 'lax' });. This command tells the browser to create a cookie named sessionId that cannot be read by JavaScript, will only be sent over HTTPS, and will only be sent on same-site requests or top-level cross-site navigations.