Cookie SameSite
Definition of ‘Site’
The site is the combination of the domain suffix and the part of the domain just before it. For example, the www.web.dev domain is part of the web.dev site.
If the user is on www.web.dev and requests an image from static.web.dev then that is a same-site request.
Caveat
The public suffix list defines this, so it’s not just top-level domains like .com but also includes services like github.io. That enables your-project.github.io and my-project.github.io to count as separate sites.
If the user is on your-project.github.io and requests an image from my-project.github.io that’s a cross-site request.
SameSite attributes
Strict
If you set SameSite to Strict, your cookie will only be sent in a first-party context. In user terms, the cookie will only be sent if the site for the cookie matches the site currently shown in the browser’s URL bar. So, if the promo_shown cookie is set as follows:
Set-Cookie: promo_shown=1; SameSite=Strict
When the user is on your site, then the cookie will be sent with the request as expected. However when following a link into your site, say from another site or via an email from a friend, on that initial request the cookie will not be sent. This is good when you have cookies relating to functionality that will always be behind an initial navigation, such as changing a password or making a purchase, but is too restrictive for promo_shown. If your reader follows the link into the site, they want the cookie sent so their preference can be applied.
Lax
That’s where SameSite=Lax comes in by allowing the cookie to be sent with these top-level navigations. Let’s revisit the cat article example from above where another site is referencing your content. They make use of your photo of the cat directly and provide a link through to your original article.
<p>Look at this amazing cat!</p><img src="https://blog.example/blog/img/amazing-cat.png" /><p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>
And the cookie has been set as so:
Set-Cookie: promo_shown=1; SameSite=Lax
When the reader is on the other person’s blog the cookie will not be sent when the browser requests amazing-cat.png. However when the reader follows the link through to cat.html on your blog, that request will include the cookie. This makes Lax a good choice for cookies affecting the display of the site with Strict being useful for cookies related to actions your user is taking.
None
Finally there is the option of not specifying the value which has previously been the way of implicitly stating that you want the cookie to be sent in all contexts. In the latest draft of RFC6265bis this is being made explicit by introducing a new value of SameSite=None. This means you can use None to clearly communicate that you intentionally want the cookie sent in a third-party context.
None specifies that cookies are sent on both originating and cross-site requests, but only in secure contexts (i.e., if SameSite=None then the Secure attribute must also be set).
Reference
SameSite cookies explained | Articles | web.dev
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite https://www.netsparker.com/blog/web-security/same-site-cookies-by-default/ https://ianhung0529.medium.com/chrome-80-%E5%BE%8C%E9%87%9D%E5%B0%8D%E7%AC%AC%E4%B8%89%E6%96%B9-cookie-%E7%9A%84%E8%A6%8F%E5%89%87%E8%AA%BF%E6%95%B4-default-samesite-lax-aaba0bc785a3 Chrome 80 後針對第三方 Cookie 的規則調整 (default SameSite=Lax) https://simonwillison.net/2021/Aug/3/samesite/ 目前，所有主流浏览器都支持 cookie 的 SameSite 属性，用来限制第三方 Cookie。但是，不同的浏览器对这个属性的实现不一样，导致这个属性的行为有非常大的差异。 https://jub0bs.com/posts/2021-01-29-great-samesite-confusion/ 浏览器有一个”同源政策”（same origin policy），Cookie 设置有一个”同站属性”（SameSite）。这篇文章介绍了 origin 和 site 的区别是什么。