What the SameSite Attribute Actually Does
Every HTTP cookie can carry a SameSite attribute that tells browsers when to include that cookie in cross-site requests. The attribute was introduced to reduce cross-site request forgery (CSRF) attacks and limit unintended data leakage, but it also has direct consequences for analytics, embedded content, and third-party cookie behaviour.
Three values are available: Strict, Lax, and None. Each controls a different level of cross-site cookie sending.
The attribute sits in the Set-Cookie HTTP response header alongside flags like Secure, HttpOnly, and Path. A typical header looks like this:
Set-Cookie: session_id=abc123; SameSite=Lax; Secure; HttpOnly; Path=/
The Three SameSite Values Compared
Each value restricts cookie sending in a different way. The table below summarises how each one behaves across common request types.
| Request Type | SameSite=Strict | SameSite=Lax | SameSite=None; Secure |
|---|---|---|---|
| Same-site navigation | Sent | Sent | Sent |
| Top-level cross-site link click | Not sent | Sent | Sent |
| Cross-site form POST | Not sent | Not sent | Sent |
| Cross-site iframe | Not sent | Not sent | Sent |
| Cross-site image/script request | Not sent | Not sent | Sent |
| Cross-site AJAX/fetch | Not sent | Not sent | Sent |
SameSite=Strict
Cookies marked Strict are only sent when the request originates from the same site. If a visitor clicks a link on an external website that leads to your domain, Strict cookies will not be included in that initial request. This can cause problems for session cookies - a logged-in user arriving from an email link would appear logged out on the first page load.
Strict is best suited to cookies that should never leave the origin context: anti-CSRF tokens, internal admin session identifiers, and security-sensitive state. Financial services and banking applications commonly choose this setting.
SameSite=Lax
The Lax value provides a middle ground. Cookies are sent on same-site requests and on top-level navigations using safe HTTP methods (primarily GET). They are not sent on cross-site sub-requests such as images, iframes, or POST forms.
This makes Lax suitable for general session cookies. A visitor clicking a link from a search engine or social media post will arrive with their session intact, but the cookie will not be attached to embedded resources loaded from other origins.
Most authentication cookies work well with Lax.
SameSite=None
Setting SameSite=None disables cross-site restrictions entirely - the cookie is sent with every request regardless of origin. This is required for cookies that genuinely need to work across sites: third-party analytics pixels, payment gateway integrations, and embedded widgets that maintain state.
Browsers enforce one strict rule: SameSite=None must be paired with the Secure flag, meaning the cookie will only be sent over HTTPS connections. Without the Secure attribute, the cookie will be rejected.
Browser Default Behaviour When SameSite Is Missing
If you set a cookie without specifying SameSite, browsers apply their own defaults. These defaults vary, which creates inconsistent behaviour across your visitor base.
As of early 2026, Chromium-based browsers (Chrome, Edge, Opera) treat cookies without an explicit SameSite attribute as Lax. This change was rolled out starting with Chrome 80 in February 2020 and is now standard across the Chromium ecosystem.
Firefox takes a different approach. Rather than defaulting to Lax, Firefox uses Enhanced Tracking Protection and Total Cookie Protection, which partitions third-party cookies per site. The underlying SameSite default remains None in Firefox, but the practical effect of cookie partitioning is similar to cross-site restriction.
Safari blocks most third-party cookies by default through Intelligent Tracking Prevention (ITP), regardless of the SameSite value. Even cookies explicitly set to SameSite=None; Secure may be blocked in third-party contexts.
The practical advice is simple: always set SameSite explicitly on every cookie. Relying on browser defaults produces unpredictable results.
How SameSite Affects Common Cookie Types
Different cookie categories call for different SameSite settings. Getting this wrong can break functionality or weaken security.
Session cookies like PHPSESSID or framework equivalents typically work best with Lax. This preserves login state for visitors arriving via external links while still blocking the cookie from being sent in cross-site sub-requests.
Anti-CSRF tokens should always use Strict. Their entire purpose is to validate same-origin requests, so cross-site sending would undermine the protection they provide.
Analytics cookies like _ga and _gid from Google Analytics are set as first-party cookies with SameSite=Lax. Since they are read by JavaScript on the same domain, cross-site sending is unnecessary.
Marketing and advertising cookies such as _fbp (Meta Pixel) or ad network identifiers often require SameSite=None; Secure because they need to function across domains for conversion tracking and retargeting. These are the cookies most affected by browser restrictions and most likely to require explicit user consent under privacy regulations.
The Secure Flag Requirement
Since 2020, all major browsers reject cookies that set SameSite=None without the Secure flag. This is not optional. If your site still serves any pages over plain HTTP, cookies with SameSite=None will not be stored by the browser.
The Secure flag ensures the cookie is only transmitted over encrypted HTTPS connections, preventing interception during transit. For modern websites, HTTPS should be the baseline for every page, not just checkout or login pages.
A cookie set as SameSite=None without Secure will be silently dropped by the browser. There is no error message in most cases - the cookie simply disappears. Checking the Application panel in Chrome DevTools will show a warning icon next to any cookie rejected for this reason.
SameSite and Privacy Regulations
The SameSite attribute is a technical mechanism, not a legal compliance tool. Setting a cookie to Strict does not exempt it from consent requirements under the ePrivacy Directive or GDPR.
Article 5(3) of the ePrivacy Directive requires prior consent for storing or accessing information on a user's device unless the cookie is strictly necessary for a service the user has explicitly requested. This obligation applies regardless of the SameSite value. A Strict analytics cookie still needs consent; a None essential payment cookie may not.
Where SameSite becomes relevant to compliance is in reducing the attack surface. Cookies with SameSite=Strict or Lax are less likely to be exploited in cross-site attacks, which supports the GDPR's data protection by design principle under Article 25. Using appropriate SameSite values is a reasonable technical measure to protect personal data stored in cookies.
Regardless of the attribute, non-essential cookies must be blocked until consent is given. A cookie management platform handles this by preventing cookie-setting scripts from firing before a visitor makes a choice.
Practical Implementation Tips
Set SameSite explicitly on every cookie your application creates. Do not rely on browser defaults.
For server-side cookies in most web frameworks, the attribute is straightforward to add. In PHP: setcookie('name', 'value', ['samesite' => 'Lax', 'secure' => true]). In Express.js, pass sameSite: 'lax' in the cookie options object. Django uses SESSION_COOKIE_SAMESITE = 'Lax' in settings.
Third-party scripts set their own cookies with their own SameSite values, and you cannot override those from your server. The only control you have is whether those scripts load at all - which is where conditional script loading based on consent becomes essential.
Test your cookie configuration across multiple browsers. Chrome DevTools flags cookies with missing or incorrect SameSite attributes in the Issues panel. Firefox's Storage Inspector and Safari's Web Inspector provide similar diagnostics.
Watch for the Partitioned attribute (CHIPS - Cookies Having Independent Partitioned State), which Chrome is introducing for cross-site cookies. Cookies set with SameSite=None; Secure; Partitioned will be stored separately per top-level site, offering a privacy-preserving alternative to unrestricted third-party cookies. This is particularly relevant for embedded widgets and payment gateway integrations.
Frequently Asked Questions
What happens if I do not set SameSite on my cookies?
Chromium-based browsers (Chrome, Edge, Opera) treat cookies without a SameSite attribute as Lax by default. Firefox and Safari handle it differently through their own tracking protection mechanisms. Always set the attribute explicitly to avoid inconsistent behaviour.
Does SameSite=Strict break login for visitors coming from external links?
Yes. If your session cookie uses Strict, visitors clicking a link from an email, search engine, or social media site will appear logged out on arrival. The cookie is not sent on the initial cross-site navigation. Use Lax for session cookies instead.
Can I use SameSite=None without the Secure flag?
No. All major browsers reject SameSite=None cookies that lack the Secure flag. The cookie will be silently dropped and will not be stored in the browser.
Does setting SameSite=Strict mean I do not need cookie consent?
No. The SameSite attribute is a security mechanism, not a legal exemption. Under the ePrivacy Directive, any non-essential cookie still requires prior consent regardless of its SameSite value.
Which SameSite value should I use for Google Analytics cookies?
Google Analytics sets its own cookies (_ga, _gid) as first-party with SameSite=Lax. You do not control these values directly, but you control whether the GA script loads at all by gating it behind cookie consent.
What is the Partitioned attribute and how does it relate to SameSite?
The Partitioned attribute (also called CHIPS) is a newer mechanism that stores cross-site cookies separately per top-level site. It works alongside SameSite=None; Secure and may become required for cross-site cookies in future browser versions.
Take Control of Your Cookie Compliance
If you are not sure which cookies your site sets or how their SameSite attributes are configured, start with a free scan. Kukie.io detects, categorises, and helps you manage every cookie - so your visitors get a clear choice, and you stay on the right side of the law.
