Cookie Attributes (Secure/HttpOnly/SameSite)

Cookie attributes (Secure, HttpOnly, SameSite) are flags set on HTTP cookies to control their security properties: encryption in transit, JavaScript access restrictions, and cross-origin sending behavior.

Category: Security (also: Web Development)

Author: Atomic Glue Security Team

## Definition

Cookies are small pieces of data stored by the browser and sent with every request to a domain. Without security attributes, cookies are vulnerable to interception (if sent over HTTP), theft via XSS (if accessible to JavaScript), and CSRF attacks (if sent cross-origin). Three critical attributes mitigate these risks: Secure (cookie is only sent over HTTPS), HttpOnly (cookie is inaccessible to JavaScript), and SameSite (controls when the cookie is sent on cross-origin requests). Setting these attributes correctly is a baseline security practice for any web application that uses cookies for sessions or authentication.

## Secure Attribute

The `Secure` flag tells the browser to only send the cookie over HTTPS connections. If set, the cookie will not be sent over unencrypted HTTP connections. This prevents network-level eavesdroppers from capturing the cookie. Without the Secure flag, a cookie can be transmitted in plaintext over HTTP, making it trivially stealable on public WiFi. Always set Secure on any cookie that contains session identifiers or authentication tokens.

## HttpOnly Attribute

The `HttpOnly` flag makes the cookie inaccessible to JavaScript's document.cookie API. This is a critical defense against XSS attacks: even if an attacker manages to inject a script, they cannot read HttpOnly cookies. Session cookies should always be HttpOnly. Without this flag, any XSS vulnerability immediately exposes all cookies to the attacker, enabling session hijacking.

## SameSite Attribute

The `SameSite` attribute controls whether cookies are sent on cross-origin requests. **Strict**: Never sent on cross-origin requests. Best security but can break legitimate cross-site navigation. **Lax** (default in modern browsers): Sent on top-level navigations using safe methods (GET), not on cross-origin POST or requests from third-party iframes. Balances security and usability. **None**: Sent on all cross-origin requests. Requires Secure flag (HTTPS). SameSite=Lax is the new default in Chrome, Edge, Firefox, and Safari, significantly reducing CSRF risk.

## Note

The default SameSite behavior changed from None to Lax in major browsers around 2020-2021. If your application relies on cross-origin cookie sending (e.g., third-party iframe widgets), you may need to explicitly set SameSite=None with Secure.

## Common questions

Q: Should all cookies be HttpOnly?

A: Session cookies and authentication tokens should always be HttpOnly. Cookies that need to be read by JavaScript (e.g., UI preference cookies) should not be HttpOnly but should still be Secure and SameSite-restricted.

Q: Can Secure cookies be set from HTTP pages?

A: No. The Secure flag means the cookie can only be set from an HTTPS page. If your site serves an HTTP page that attempts to set a Secure cookie, the cookie is silently rejected.

Q: What is the cookie prefix __Host-?

A: The __Host- prefix enforces that a cookie is Secure, has Path=/, and is not sent from a different domain. This is a defense against cookie injection attacks in subdomain scenarios.

## Key takeaways

• Secure: cookie only sent over HTTPS.
• HttpOnly: cookie inaccessible to JavaScript (blocks XSS cookie theft).
• SameSite: controls cross-origin cookie sending (default is Lax).
• All three attributes should be set on session and authentication cookies.

## Related entries

• [CSRF](atomicglue.co/glossary/csrf)
• [XSS](atomicglue.co/glossary/xss)
• [HTTPS / TLS](atomicglue.co/glossary/https-tls)

Last updated December 2024. Permalink: atomicglue.co/glossary/cookie-attributes