Skip to main content
Cookie Gate
Category: Tracking Technologies

Same-Site Cookies

Also known as: SameSite Cookie Attribute, SameSite attribute
Simply put

The SameSite attribute is a browser setting attached to a cookie that tells the browser whether to send that cookie when a request comes from another website. It is primarily a security control that helps limit how cookies travel between different sites, reducing certain cross-site attacks. It is a technical mechanism rather than a consent or privacy-law feature in itself.

Formal definition

SameSite is an attribute set on a cookie (via the Set-Cookie response header) that instructs the browser on whether to include the cookie with cross-site requests, thereby distinguishing first-party from third-party cookie contexts. Its recognized values are Strict, Lax, and None, where None permits the cookie to be sent with both cross-site and same-site requests but generally requires the Secure attribute to also be set. The attribute's primary purpose is security, mitigating cross-site request forgery (CSRF) and unintended cross-origin information disclosure by controlling cross-site transmission. Note that SameSite governs cookie transmission behavior at the browser level and does not, by itself, address consent obligations under the ePrivacy Directive or the processing of personal data under the GDPR; those legal requirements are out of scope for this attribute and must be handled separately.

Why it matters

The SameSite attribute is one of the primary browser-level mechanisms for controlling whether a cookie is sent with requests originating from other websites. Its main purpose is security: by restricting cross-site transmission, it helps mitigate cross-site request forgery (CSRF) and unintended cross-origin information disclosure. For teams building and maintaining web applications, correctly setting SameSite values is a practical safeguard against certain classes of cross-site attacks.

SameSite also matters because it draws a technical line between first-party and third-party cookie contexts, which increasingly overlaps with how privacy and consent are managed in practice. Cookies set with SameSite=None are, in effect, permitted to travel in cross-site contexts and therefore commonly correspond to the third-party tracking scenarios that attract consent obligations. However, it is important not to overstate this relationship: SameSite is a transmission control, not a consent or privacy-law feature. Setting or restricting SameSite does not, by itself, satisfy or discharge any legal obligation.

For compliance and legal teams, the key takeaway is scope. SameSite governs browser behavior at the technical level; it does not address consent obligations under the ePrivacy Directive or the processing of personal data under the GDPR. Those requirements must be handled separately through consent management and lawful-basis analysis. Treating SameSite as if it resolves privacy questions would be a misreading of what the attribute does.

Who it's relevant to

Web Developers and Engineers
Developers are responsible for setting SameSite values (Strict, Lax, or None) via the Set-Cookie header and for ensuring that cookies using SameSite=None also carry the Secure attribute. Correct configuration helps mitigate CSRF and unintended cross-origin information disclosure, making SameSite a routine part of secure application development.
Security Teams
Security professionals rely on SameSite as one control among several to reduce the risk of cross-site request forgery and cross-origin information leakage. Because it is a browser-level mechanism, it should be treated as part of a broader defense strategy rather than a standalone protection.
Privacy and Compliance Professionals
Privacy officers and legal counsel should understand that SameSite distinguishes first-party from third-party cookie contexts, which often overlaps with the cookies that attract consent obligations. However, they should be aware that SameSite is a technical control only and does not, by itself, address consent under the ePrivacy Directive or personal data processing under the GDPR; those obligations must be managed separately.

Inside Same-Site Cookies

SameSite attribute
A cookie attribute that instructs the browser whether to send a cookie along with cross-site requests, providing a browser-level control over cross-site cookie transmission. It is set by the server when the cookie is created.
SameSite=Strict
A value that generally prevents the browser from sending the cookie with any cross-site request, including top-level navigations originating from another site. This offers the tightest restriction but can affect user experience when arriving from external links.
SameSite=Lax
A value that typically allows the cookie to be sent on top-level navigations using safe methods (such as following a link) while withholding it from most other cross-site contexts. It is commonly treated as the default behaviour by many modern browsers when no SameSite value is specified.
SameSite=None
A value that permits the cookie to be sent in cross-site contexts, which is often required for embedded third-party functionality. Modern browsers generally require this value to be paired with the Secure attribute so the cookie is only transmitted over HTTPS.
First-party versus third-party context
SameSite behaviour depends on whether a request is same-site or cross-site relative to the site the user is visiting, which is central to how the attribute limits cookies used in embedded or cross-domain scenarios.
Security purpose
The SameSite attribute is primarily a technical security control aimed at mitigating certain cross-site request risks. It is a browser mechanism rather than a legal consent or compliance mechanism.

Common questions

Answers to the questions practitioners most commonly ask about Same-Site Cookies.

Does setting the SameSite attribute make a cookie compliant with cookie consent laws?
No. The SameSite attribute is a security and cross-site behavior control implemented at the browser level; it addresses risks such as cross-site request forgery and limits when cookies are sent in cross-site contexts. It does not address the separate legal question of whether you may place or read a cookie in the first place. In most EU jurisdictions, the ePrivacy rules governing the placing of and access to information on a user's device, and the GDPR rules governing any resulting processing of personal data, apply regardless of a cookie's SameSite setting. SameSite therefore supports technical hygiene but does not constitute or replace consent where consent is required.
Does the SameSite attribute determine whether a cookie is first-party or third-party?
Not exactly. SameSite governs whether a cookie is sent in cross-site request contexts, which is a different concept from how a cookie is classified for consent and disclosure purposes. A cookie's first-party or third-party character generally relates to the domain that sets it and the parties who have access to the data, whereas SameSite=Lax, Strict, or None describes the browser's send behavior across sites. The two concepts interact but are not interchangeable, and the consent and transparency analysis under EU and other frameworks does not turn on the SameSite value alone.
What are the possible values of the SameSite attribute and what does each do?
The SameSite attribute generally accepts three values. Strict typically means the cookie is only sent in a first-party context and not on cross-site requests. Lax generally allows the cookie to be sent on top-level navigations to your site but restricts it in other cross-site contexts. None means the cookie may be sent in cross-site contexts, and modern browsers generally require that SameSite=None cookies also carry the Secure attribute, meaning they are only transmitted over HTTPS. Exact browser behavior can vary between vendors and versions, so testing across your target browsers is advisable.
Which SameSite value should I use for cookies involved in cross-site tracking or embedded third-party content?
Cookies intended to function across sites, such as those used by embedded third-party content, generally require SameSite=None together with the Secure attribute so that browsers will transmit them in cross-site contexts. However, choosing a value that technically enables cross-site behavior does not by itself make that behavior lawful. In most EU jurisdictions, cross-site tracking, advertising, and similar cookies typically require prior consent, and similar technologies such as pixels and SDKs fall within the same rules. Requirements differ under US state privacy laws, which often rely on opt-out mechanisms rather than opt-in. Configure SameSite based on the technical function you need, and address the consent question separately according to the applicable jurisdiction.
Do I need to disclose the SameSite setting in my cookie policy or CMP?
There is generally no specific obligation to disclose the SameSite attribute value itself. Transparency obligations in most EU jurisdictions focus on informing users about the cookies and similar technologies used, their purposes, duration, and the parties involved, rather than on low-level technical attributes like SameSite. That said, the underlying cookie still needs to appear in your cookie inventory, categorization, and disclosures where required. Treat SameSite as an implementation detail and ensure your policy and consent management platform accurately describe the cookie's purpose and the parties with access.
How does the SameSite attribute interact with a consent management platform (CMP) that blocks cookies before consent?
A CMP that suppresses or blocks non-essential cookies before consent operates independently of the SameSite attribute. The CMP is concerned with whether a cookie is placed or read at all based on the user's consent state, while SameSite governs the browser's send behavior once a cookie exists. In practice, you would configure the CMP to control when consent-dependent cookies are set, and separately set SameSite on those cookies for their technical cross-site behavior. Neither mechanism substitutes for the other, and a CMP supports but does not by itself guarantee compliance; legal judgment remains necessary.

Common misconceptions

Setting SameSite on cookies satisfies cookie consent or privacy law obligations.
SameSite is a technical, security-oriented browser attribute governing when cookies are sent with requests. It does not address whether the placing of or access to information on a user's device is lawful, nor whether valid consent has been obtained where required. Under EU rules, the need for prior consent for non-essential cookies is generally independent of the SameSite value; SameSite supports security, not compliance, and does not replace legal judgment.
SameSite=Strict makes a cookie exempt from consent because it is more restrictive.
The consent requirement in most EU jurisdictions generally depends on the purpose of the cookie (for example, whether it is strictly necessary versus used for analytics or advertising), not on its SameSite value. A more restrictive SameSite setting does not change how a cookie is categorised for consent purposes.
SameSite=None blocks or replaces the need to manage cross-site tracking.
SameSite=None actually permits cookies to be sent in cross-site contexts and is often used to enable third-party functionality. It does not by itself impose or remove any consent obligation, and similar cross-site tracking concerns can also arise with technologies that are not literally cookies, such as pixels, local storage, or fingerprinting.

Best practices

Treat the SameSite attribute as a technical security control and continue to apply separate consent and record-keeping measures where non-essential cookies require prior consent under applicable EU or UK rules.
Explicitly set a SameSite value on each cookie rather than relying on undefined behaviour, and document the chosen value alongside the cookie's purpose and legal categorisation.
Pair SameSite=None with the Secure attribute so such cookies are only transmitted over HTTPS, consistent with modern browser expectations.
Categorise cookies by purpose (for example, strictly necessary versus analytics or advertising) independently of their SameSite setting, since consent obligations generally follow purpose rather than the attribute.
Review embedded third-party and cross-domain functionality that may rely on SameSite=None, and confirm that any associated data processing and consent requirements are addressed, keeping in mind that pixels, SDKs, and local storage may fall within the same rules.
Test cookie behaviour across current browser versions, since default treatment of unspecified SameSite values and cross-site handling can differ between browsers and evolve over time.