1. 相关术语

一方 & 三方

技术上看没区别，都是浏览器用来存储数据的一种文件。不同之处在于网站如何创建和使用它们。

一方cookie：由当前直接访问的域创建，通常是被信任的，主要用于提供更好的用户体验，如会话保持，添加购物车，语言首选项，多主题等。
三方cookie：由直接访问的域以外的域创建的，主要用途：跨站点跟踪，SSO，在线广告，数据统计，实时聊天。 OpenApi走api的鉴权认证机制(accesskey+secretkey)，不应使用三方cookie。

同源 & 同站

同源：协议，域名，端口一致。Form表单提交不受同源限制，当心csrf漏洞
同站：只要两个URL的eTLD+1相同即可，不需要考虑协议和端口。其中，eTLD 表示有效顶级域名，注册于 Mozilla 维护的公共后缀列表（Public Suffix List）中，例如，.com、.co.uk、.github.io 等。eTLD+1 则表示，有效顶级域名+二级域名，例如 taobao.com 等。

eTLD
eTLD 的全称是 effective Top-Level Domain，它与我们往常理解的 Top-Level Domain 顶级域名有所区别。eTLD 记录在之前提到的 PSL 文件中。而 TLD 也有一个记录的列表，那就是 Root Zone Database。eTLD 的出现主要是为了解决 .com.cn, .com.hk, .co.jp 这种看起来像是一级域名的但其实需要作为顶级域名存在的场景。
举个例子：例如 .org 是在 PSL 中记录的有效顶级域名，abc.org 则是一级域名。所以 https://blog.abc.org 和 https://www.abc.org 是同站域名。而 .github.io 也是在 PSL 中记录的有效顶级域名，所以 https://www.github.io 和 https://blog.github.io 得到的一级域名是不一样的，他们两个是跨站域名。

同源限制ajax请求，同站限制cookie，localStorage?(同源)

2. Samesite

背景：为了解决csrf问题，Chrome 于 2015 年 6 月为Cookie增加了Samesite属性，Firefox 和 Safari 紧随其后也增加了支持。SameSite 属性有以下几个值：

None：无论是否跨站都会发送 Cookie
Lax：允许部分第三方请求携带 Cookie
Strict：仅允许同站请求携带 Cookie
image.png

2.1 注意

  1. HTTP 接口不支持 SameSite=None

如果你想加 SameSite=None 属性，那么该 Cookie 就必须同时加上 Secure 属性，表示只有在 HTTPS 协议下该 Cookie 才会被发送。

  1. Set-Cookie: name=gongzhen; SameSite=None; Secure
  1. 需要 UA 检测，部分浏览器不能加 SameSite=None

IOS 12 的 Safari 以及老版本的一些 Chrome 会把 SameSite=None 识别成 SameSite=Strict，所以服务端必须在下发 Set-Cookie 响应头时进行 User-Agent 检测，对这些浏览器不下发 SameSite=None 属性。

2.2 时间点

2015年6月（Chrome51）推出Samesite属性，默认值为None。
2020年2月（Chrome80）将默认值改为lax进行灰度，但由于影响广泛，需要网站维护者花大量时间去修改适配，且全球开始面临新冠疫情的影响，在后续的版本里又暂时先回退了这个特性（相关链接）。
2020年7月14日（Chrome 84稳定版）开始重新恢复SameSite cookie策略。
最终在2020年9月（Chrome 86）进行了全量操作。

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