SameSite Cookie Attributes: Strict vs Lax vs None

The SameSite attribute is a critical security mechanism built into modern HTTP cookies to mitigate Cross-Site Request Forgery (CSRF) attacks and restrict third-party data tracking. By dictating whether cookies are sent alongside cross-site HTTP requests, this attribute allows developers to define clear boundaries between first-party user sessions and third-party contexts. The three available directives—Strict, Lax, and None—offer varying trade-offs between strict security isolation and cross-site user experience.

Context: Defining "Site" in Cross-Site Requests

To understand SameSite, it is necessary to distinguish between an origin and a site:

• An origin is defined by the exact combination of scheme, host, and port (e.g., https://example.com:443).
• A site is determined by the scheme and the registrable domain, known as the effective top-level domain plus one level (eTLD+1). For instance, https://app.example.com and https://api.example.com belong to the same site (https://example.com).

A request is considered "cross-site" when the destination site differs from the site of the page initiating the request.

SameSite=Strict

When a cookie is configured with SameSite=Strict, the browser will never include the cookie in any cross-site request.

• Behavior: The cookie is restricted exclusively to first-party contexts. If a user is on https://external.com and clicks a standard hyperlink pointing to https://example.com, any cookies marked Strict on example.com will not be attached to that initial request. The cookie will only be transmitted once the user performs a navigation originating from within example.com.
• Subresources: Blocked. Images, scripts, or iframe requests loaded from an external site cannot send Strict cookies.
• Security Profile: Provides the highest defense against CSRF attacks, as unauthorized external origins cannot force an authenticated request.
• Trade-off: Degraded user experience. If a user follows a link from an email client, chat application, or external website to a service where they hold an active session, they will initially appear logged out until they reload or navigate within the target site.

SameSite=Lax

SameSite=Lax serves as a middle ground between security and usability. It is the default setting implemented by most modern browsers (such as Chrome, Edge, and Firefox) when a cookie does not explicitly specify a SameSite directive.

• Behavior: The cookie is withheld on most cross-site requests, but it is permitted during top-level navigations that use safe HTTP methods (typically GET).
• Allowed Contexts: Clicking a standard anchor tag (<a href="...">), a client-side redirect using window.location, or an HTTP redirect leading to the target site will include the cookie.
• Blocked Contexts: State-changing cross-site requests—such as <form method="POST">, fetch() calls, or XMLHttpRequest—do not send Lax cookies. Embedded cross-site subresources (such as <img>, <audio>, or <iframe> tags) are also blocked from sending the cookie.
• Security Profile: Prevents standard CSRF attacks that rely on POST submissions or background asynchronous requests while maintaining seamless login states for users entering via external links.

SameSite=None

The SameSite=None directive explicitly disables same-site restrictions, permitting the browser to attach the cookie to all cross-site and first-party requests alike.

• Behavior: The cookie behaves like a traditional third-party cookie. It is sent on standard links, embedded subresources (<img>, <iframe>), cross-origin POST requests, and asynchronous JavaScript requests (provided credentials are enabled).

• The Secure Requirement: Modern browser specifications mandate that any cookie carrying SameSite=None must also include the Secure attribute. If a cookie is set as SameSite=None without Secure, the browser rejects the cookie entirely:

  Set-Cookie: session_id=xyz123; SameSite=None; Secure

• Use Cases: Required for cross-site integrations, embedded third-party widgets (e.g., payment gateways, chat windows, embedded videos), and shared APIs operating under different parent domains.

• Security Profile: Offers zero native CSRF protection. Developers relying on SameSite=None must implement independent CSRF countermeasures, such as anti-CSRF tokens or custom request headers.

Technical Comparison