The SameSite attribute is a security setting for HTTP cookies that controls how they are sent during cross-site requests. It allows you to declare whether a cookie should be restricted to a first-party context or allowed for third-party usage. Managing this attribute correctly protects users from security vulnerabilities and ensures website features like embedded content and logins work as intended.
What is the SameSite Attribute?
The [SameSite attribute is defined in the RFC6265bis standard] (web.dev) to help browsers identify how to handle cookies. It defines the relationship between the "site" the user is visiting and the "site" that set the cookie.
In this context, a "site" is the combination of the domain suffix (like .com) and the part of the domain immediately before it. For example, static.web.dev is considered part of the same site as www.web.dev. To determine these boundaries, browsers use the [Public Suffix List to distinguish between different sites on shared platforms] (web.dev), such as your-project.github.io and my-project.github.io.
Why SameSite Attribute matters
The attribute is a critical tool for security, privacy, and technical compliance.
- Prevents CSRF attacks. It restricts cookies from being sent in cross-site requests, which stops malicious sites from forging authorized commands on behalf of a user.
- Enhances user privacy. By limiting cookie exchange between different domains, it prevents sensitive personal data from being exposed to third parties.
- Ensures browser compatibility. Modern browsers have strict default behaviors. [Chrome, Edge, and Opera treat cookies as Lax by default as of late 2024] (OWASP Foundation).
- Protects sensitive information. It helps mitigate cross-origin information leakage, ensuring session data remains within the intended domain.
How SameSite Attribute works
When a browser makes a request, it checks the SameSite attribute of every stored cookie to decide if it should be included.
- Strict: The cookie is only sent if the request originates from the same site shown in the browser's address bar. It is never sent when following a link from an external site.
- Lax: The cookie is withheld from cross-site resource requests, such as images or scripts. However, it is sent during "top-level" navigations, such as when a user clicks a link from a different site to yours.
- None: The cookie is sent in all contexts, including cross-site requests. This is required for widgets, embedded content, and affiliate programs.
Under the [Incrementally Better Cookies proposal] (web.dev), any cookie set to None must also use the Secure attribute. This means the cookie can only be sent over encrypted HTTPS connections.
SameSite Attribute Values
| Value | When it is sent | Use Case |
|---|---|---|
| Strict | Only for same-site requests. | Financial services, passwords, or transactional actions. |
| Lax | Same-site requests + top-level GET links. | Most general websites to maintain logged-in states. |
| None | All requests (same-site and cross-site). | Third-party embeds, analytics, and SSO systems. |
Best practices
Analyze your application needs. Use Strict for high-risk actions like changing passwords. Use Lax for most cookies that affect website display to ensure a smooth transition when users arrive from search engines.
Explicitly set the attribute. Don't rely on browser defaults, as they can vary. While [Chrome 80 began treating cookies without an attribute as Lax by default] (Cookie-Script), setting it explicitly ensures consistent behavior across all browsers.
Pair None with Secure. If you must use SameSite=None for third-party features, you must also add the Secure flag. Browsers will [reject cookies set to None that lack the Secure attribute] (web.dev).
Verify with developer tools. Use your browser's application or storage tab to inspect cookies. Check for warnings regarding SameSite or Secure requirements to identify broken cookies before they affect users.
Common mistakes
Mistake: Using SameSite=None without the Secure attribute.
Fix: Always add the Secure flag when using None so the browser does not reject the cookie.
Mistake: Setting everything to Strict.
Fix: Use Lax for cookies that impact user experience when arriving from external links. If a session cookie is Strict, a user clicking a link from an email or social media post will appear logged out when they arrive at your site.
Mistake: Relying on browser defaults for sensitive data.
Fix: Manually define Strict or Lax for all sensitive cookies. [Firefox 69 and Chrome have established different implementation timelines for these defaults] (Cookie-Script), and explicit settings avoid confusion.
Examples
Example scenario: Financial Transaction
A bank sets a session cookie as Set-Cookie: session_id=123; SameSite=Strict; Secure. If a user is on a malicious site that tries to trigger a transfer on the bank's site, the browser will not send the session cookie, and the request will fail.
Example scenario: External Blog Link
A website uses Set-Cookie: preference=dark; SameSite=Lax. When a user clicks a link from a review site to visit this website, the browser sends the cookie. The user sees the site in dark mode immediately upon landing.
Example scenario: Third-Party Widget
An analytics provider sets a cookie as Set-Cookie: tracker_id=abc; SameSite=None; Secure. Because it is marked as None, the cookie is sent even when the tracker is loaded as a third-party script on various different websites.
FAQ
What is the SameSite cookie attribute?
It is a security identifying flag sent in the HTTP response header. It tells the browser whether a cookie should be shared with other websites or restricted to the site that created it. [SameSite was first introduced by Google on its Chrome browser in 2020] (Cookie-Script) to modernize how browsers manage privacy and security.
How do I fix SameSite cookie problems?
Most problems occur when a third-party cookie is rejected because it lacks the None and Secure attributes. To fix this, update your server settings to include SameSite=None; Secure. If a first-party cookie is missing when a user clicks a link to your site, ensure it is set to Lax rather than Strict.
What does SameSite Lax mean?
Lax is a balanced setting where the browser prevents cookies from being sent on cross-site sub-resource requests (like images) but allows them when a user follows a link to the site. Browsers now [treat cookies without the attribute as Lax by default, a change introduced in Chrome 80] (web.dev).
When should I use SameSite Strict?
Use Strict for any cookie related to sensitive user actions that do not require a persistent login state when coming from an external link. This is the [most aggressive form of CSRF protection] (Cookie-Script) because it ensures the cookie is only sent if the user is already navigating within your domain.
Where can I check my SameSite settings?
In Chrome or Edge, open Developer Tools and go to the Application tab, then select Cookies. In Firefox, go to the Storage tab. These sections will list all active cookies and their SameSite status, highlighting those that do not comply with modern standards.
