Category: Tracking Technologies

SameSite Attribute

Also known as: SameSite cookie attribute, SameSite

Simply put

The SameSite attribute is a setting that a website can apply to a cookie to control whether the browser sends that cookie when a user arrives from or interacts with a different website. It is commonly used to help reduce certain cross-site attacks, such as cross-site request forgery (CSRF). It is a technical control over how cookies behave across sites, not a mechanism for obtaining user consent.

Formal definition

SameSite is an optional attribute of the HTTP Set-Cookie response header, defined in RFC 6265bis, that lets a developer declare whether a cookie should be restricted to a first-party or same-site context. It accepts values such as Strict, Lax, and None, which govern whether the browser attaches the cookie to cross-site requests; Strict withholds the cookie from cross-site requests, while Lax and None permit it under differing conditions. The attribute is implemented across major browsers, and its primary security use case is mitigating cross-site request forgery. Note that SameSite is a browser-level technical control affecting cookie transmission behavior and does not, by itself, address consent obligations under the ePrivacy Directive or personal-data processing obligations under the GDPR; those requirements must be assessed separately. This definition does not cover the detailed per-browser default behaviors or their evolution over time, which may vary and change.

Why it matters

The SameSite attribute matters primarily as a security control rather than a consent mechanism. By declaring whether a cookie should accompany cross-site requests, developers can reduce the risk of certain cross-site attacks, most notably cross-site request forgery (CSRF). For organizations building web applications that rely on cookies for session management, configuring SameSite appropriately is a recognized part of defensive coding practice, and it is supported across major browsers.

For compliance teams, the more important point is what SameSite does not do. Setting a cookie to Strict, Lax, or None affects only how the browser transmits that cookie across sites; it says nothing about whether the placing of the cookie or any subsequent processing of personal data is lawful. Consent obligations under the ePrivacy Directive and its national implementations, and personal-data processing obligations under the GDPR, must be assessed separately. A well-configured SameSite value does not substitute for a valid legal basis or for obtaining consent where consent is required.

Because SameSite is a technical attribute that governs cross-site behavior, it can be relevant when reasoning about third-party cookies and cross-site tracking, but it should not be treated as a privacy control in its own right. Teams that conflate a security-oriented attribute with a consent obligation risk overlooking distinct requirements that apply regardless of how cookies are technically transmitted.

Who it's relevant to

Web Developers and Engineers

Developers set the SameSite attribute when configuring cookies and choose among Strict, Lax, and None based on how a cookie needs to behave across sites. It is a core consideration for mitigating cross-site request forgery and for controlling whether cookies are sent with cross-site requests. Because default browser behavior may vary and change over time, engineers should verify current behavior across the browsers they support.

Security Teams

For those responsible for application security, SameSite is a recognized control that helps reduce certain cross-site attacks, particularly CSRF. It is one layer among broader defensive measures and should be evaluated alongside other protections rather than relied upon in isolation.

Privacy and Compliance Professionals

Privacy officers and compliance teams should understand that SameSite is a technical control over cookie transmission, not a consent mechanism. It does not by itself satisfy consent obligations under the ePrivacy Directive or processing obligations under the GDPR, which must be assessed separately. Consent management and legal basis remain distinct requirements regardless of how a cookie's SameSite value is configured.

Inside SameSite Attribute

SameSite=Strict

A value that restricts a cookie to being sent only in a first-party context, meaning the browser will not include it on any cross-site request, including navigation from an external link. This offers the strongest protection against cross-site request forgery but can interfere with legitimate cross-site flows such as returning to a logged-in session from an external link.

SameSite=Lax

A value that allows a cookie to be sent on top-level cross-site navigations (for example, following a link) using safe HTTP methods, while withholding it from most other cross-site contexts such as embedded resources or cross-site POST requests. Many modern browsers apply Lax as the default behaviour when no SameSite attribute is explicitly set, though exact defaults have varied between browsers and versions.

SameSite=None

A value that permits a cookie to be sent in cross-site contexts, which is typically required for third-party cookies used in embedded content, cross-site tracking, or federated flows. In most current browsers, SameSite=None must be paired with the Secure attribute so the cookie is only transmitted over HTTPS.

Relationship to the Secure attribute

A separate cookie attribute that ensures a cookie is only sent over encrypted (HTTPS) connections. It is generally required alongside SameSite=None and is often used together with SameSite settings as part of a broader cookie-hardening approach.

Scope of protection

The SameSite attribute is a technical browser-level control aimed primarily at security concerns such as cross-site request forgery and at limiting some cross-site cookie transmission. It governs how the browser handles a cookie, not whether placing or reading that cookie is lawful.

Common questions

Answers to the questions practitioners most commonly ask about SameSite Attribute.

Does setting the SameSite attribute make a cookie compliant with consent requirements?

No. The SameSite attribute is a browser security control that governs when a cookie is sent in cross-site requests, primarily to mitigate risks such as cross-site request forgery. It does not address whether consent was validly obtained for placing or reading the cookie. Consent obligations under the ePrivacy Directive (as implemented nationally in the EU) and any related processing under the GDPR are separate matters that SameSite does not satisfy. A cookie can carry a SameSite value and still be unlawful if the required prior consent was not collected where applicable.

Is a cookie marked SameSite=Strict automatically a strictly necessary or essential cookie?

No. The SameSite attribute and the concept of a strictly necessary cookie are unrelated. SameSite is a technical directive about cross-site sending behavior, whereas whether a cookie is essential (and therefore may be exempt from consent in most EU jurisdictions) depends on its purpose and function. An analytics or advertising cookie set with SameSite=Strict remains an analytics or advertising cookie and typically still requires consent under EU law. The attribute value carries no legal classification.

What SameSite values are available and what do they broadly do?

The attribute generally accepts three values: Strict, which limits the cookie to same-site requests; Lax, which permits the cookie on certain top-level navigations; and None, which allows the cookie in cross-site contexts. Where SameSite=None is used, browsers commonly require the Secure attribute so the cookie is only sent over HTTPS. Exact behavior and defaults can vary between browsers and versions, so testing against your target browsers is advisable rather than relying on assumed behavior.

How does the SameSite attribute interact with third-party cookies used for tracking?

Third-party and cross-site use cases typically depend on SameSite=None with Secure, because the more restrictive Strict and Lax values limit cross-site sending. Setting a cookie to be usable across sites in this way does not lessen any applicable consent obligations; cross-site tracking cookies generally require prior consent in most EU jurisdictions. Note also that similar technologies such as pixels, SDKs, and browser storage fall within the same consent rules even though the SameSite attribute itself applies to cookies.

Should a consent management platform (CMP) be configured to consider SameSite settings?

A CMP's role is to gather, manage, and record consent and to help control when non-essential cookies and similar technologies are set. The SameSite attribute is set on individual cookies at the technical level, typically by the application or the party issuing the cookie, rather than being the CMP's function. Coordination between how cookies are configured technically and how consent is enforced can support an overall compliance approach, but a CMP does not replace correct cookie configuration, and neither element alone guarantees compliance.

What should I check when auditing SameSite configuration on a site?

A practical audit may include confirming which value each cookie carries, whether SameSite=None cookies also carry Secure, and how the chosen values behave across the browsers your users rely on. Because browser handling and defaults can evolve, verifying actual behavior through testing is generally more reliable than assuming a default. This audit is a technical exercise and should sit alongside, not in place of, a separate review of consent, cookie classification, and record-keeping under the applicable legal regime, which depends on facts beyond the attribute itself.

Common misconceptions

Setting SameSite correctly makes cookie use compliant with the ePrivacy Directive or GDPR.

SameSite is a technical attribute controlling when browsers transmit cookies; it does not constitute or replace consent. In most EU jurisdictions, placing or accessing non-essential cookies still requires prior consent under ePrivacy rules, and any resulting personal data processing remains subject to the GDPR, regardless of the SameSite value used.

SameSite=None disables tracking, or SameSite=Strict blocks all tracking.

SameSite controls cross-site transmission of a given cookie, not tracking as a practice. SameSite=None is typically used to enable cross-site cookies, while Strict or Lax constrain them, but tracking can also occur through other technologies such as pixels, local storage, SDKs, or fingerprinting, which fall outside the reach of this attribute.

Browser defaults for SameSite are the same everywhere, so the attribute rarely matters.

Default behaviour has differed across browsers and versions, and relying on an implicit default can produce inconsistent results. Explicitly setting the intended value is generally advisable rather than assuming a uniform default.

Best practices

Set the SameSite attribute explicitly on each cookie rather than relying on browser defaults, since defaults have varied between browsers and versions.

Pair SameSite=None with the Secure attribute so cross-site cookies are only transmitted over HTTPS, as most current browsers require.

Choose the most restrictive value that still supports the intended functionality, using Strict or Lax where cross-site transmission is not needed and reserving None for genuine cross-site use cases.

Treat SameSite as a security and technical control, and maintain a separate, valid consent mechanism for non-essential cookies to address ePrivacy and GDPR obligations in the EU and comparable requirements in other jurisdictions.

Remember that similar technologies such as pixels, local storage, SDKs, and fingerprinting are not governed by SameSite, and assess them under the applicable consent and data protection rules.

Test cookie behaviour across the browsers your users rely on, and document the SameSite configuration alongside consent records to support your record-keeping and internal review, recognising that these technical settings support but do not by themselves establish legal compliance.