29

Is setting Same-Site attribute of a cookie to Lax the same as not setting it at all? If there are differences what are they?

Anders
  • 64,406
  • 24
  • 178
  • 215
user157829
  • 393
  • 1
  • 3
  • 4

3 Answers3

34

Is setting Same-Site attribute of a cookie to lax the same as not setting the Same-Site attribute?

In Google Chrome < 76 – no. Setting SameSite=lax is safer than omitting the attribute. (But if your implementation currently relies on cross-origin requests, double-check that adding the attribute doesn't break anything.)

Here are the differences:

  • When you don't set the SameSite attribute, the cookie is always sent.

  • With SameSite=lax, the cookie is only sent on same-site requests or top-level navigation with a safe HTTP method. That is, it will not be sent with cross-domain POST requests or when loading the site in a cross-origin frame, but it will be sent when you navigate to the site via a standard top-level <a href=...> link.

  • With SameSite=strict (or an invalid value), the cookie is never sent in cross-site requests. Even when clicking a top-level link on a third-party domain to your site, the browser will refuse to send the cookie.

Starting with Chrome 76, your browser has an option to make no SameSite behave like Samesite=Lax. This will be default in Chrome 80. From the feature description:

The Stable version of Chrome 80 is targeted for enabling this feature by default. The feature will be enabled in the Beta version only, starting in Chrome 78. This feature is available as of Chrome 76 by enabling the same-site-by-default-cookies flag.

Also have a look at the RFC draft and Sjoerd's blog post.

Community
  • 1
Arminius
  • 43,922
  • 13
  • 140
  • 136
  • "currently limited" means limited to just chrome and clones... good answer btw. – dandavis Aug 28 '17 at 23:43
  • Firefox supports SameSite since Firefox 60 and was released May 9, 2018 – Jonas Lejon Nov 19 '18 at 07:03
  • The 3rd bullet point doesn’t make sense to me. Are you saying if I click on a link from a third-party domain into my site that the first page load will not send my site’s `SameSite=strict` cookies to my site’s server? – MrColes Oct 09 '19 at 15:11
  • 1
    @MrColes Correct, do you find it confusingly phrased? – Arminius Oct 09 '19 at 19:17
  • 1
    @Arminius ok, sounds like I understand it then, and I was maybe making bad assumptions as to how one would use each. Seems like if you had a session cookie on a site, then as long as you don’t want it inside an iframe from a 3rd party site it should be `SameSite=lax`, because you’d need it on first page loads. However, if you want a cookie to *only* be sent on additional requests that page makes (ajax, images, css, etc. if on same site) then it could be `SameSite=strict`? – MrColes Oct 10 '19 at 17:40
  • 2
    @MrColes Exactly! Also note how enforcing `lax`/`strict` makes vulnerabilities like CSRF increasingly hard to exploit. – Arminius Oct 10 '19 at 18:04
3

This is currently changed in Chrome - and this means that not setting SameSite is actually considered LAX.

https://blog.chromium.org/2019/05/improving-privacy-and-security-on-web.html

Ran Davidovitz
  • 131
  • 1
1

Chrome recently implemented the SameSite=Lax by default if SameSite=None is not explicitly specified.

Additionally, the Secure attribute MUST be set when specifying SameSite=None, if not Chrome will ignore it.

https://www.chromestatus.com/feature/5088147346030592

JamesPoppycock
  • 11
  • 1