Cookie

第一方cookie和第三方cookie

第一方cookie：你正在浏览的域所建立的Cookie，比如你正在访问百度的官网baidu.com，那么你的浏览器将会生成一个baidu.com域的Cookie保存起来。

第三方cookie：三方指的是非同站，这个同站和同源协议中的源origin不同，它的要求更宽松。同源是指协议+域名+端口三者相同，有一个不同就不算同源，而同站只受域名的约束，只要顶级域名+二级域名相同，都算同站。比如正在访问百度的网页，该网页嵌入了淘宝的广告，此时淘宝会生成一个cookie，即为第三方cookie。比如网站A和网站B都要访问网站C的资源，用户在访问网站A时，网站C会生成一个cookie唯一标识用户，用户在访问网站B时，网站B会请求网站C的资源，浏览器会直接将这个cookie发送到网站C，也就是说即使用户访问不同的网站，只要这些网站都嵌入了网站C，这个cookie就是唯一的，所以网站C可以综合用户在不同网站的行为分析用户，做到精准推荐(隐私泄露)。第三方Cookie被广泛用在单点登陆中，比如你在某宝登陆后就无需在某猫再登陆一次。

cookie的属性

1. domain

指定cookie未来使用时，可以被携带到哪些域名。其值可以设置为当前服务端的父级域名或其本身，比如ai.taobao.com设置的cookie的domain可以为.taobao.com，所设置值的所有子域名都可以使用，比如www.taobao.com。如果不设置，会默认为当前域名ai.taobao.com，并且只有自己可以使用，子域名sub.ai.taobao.com都不能使用，适用范围就小了很多，所以一般都会设置。

2. path

指定cookie未来使用时，可以被携带到合法域名的哪些URI。和domain很像，也只能设置为当前路径的父级路径或其本身,设置值的所有子路径都可以访问。

3. expire和max-age

指定cookie的有效期，其中expire是一个绝对时间，max-age是相对时间，单位是秒，两者同时存在时，max-age优先级更高；如果两者都没有，则为会话级别的cookie，即用户关闭浏览器时失效。

4. secure

设置cookie仅在使用安全协议时传输。当 secure 值为 true 时，cookie 在 HTTP 中是无效，在 HTTPS 中才会被携带传输。使用 HTTPS 安全协议，可以保护 Cookie 在浏览器和 Web 服务器间的传输过程中不被窃取和篡改。

5. http-only

禁止客户端脚本通过 document.cookie 获取cookie，避免XSS攻击。

6. SameSite

cookie的domain字段很关键，它规定请求哪些域名才会携带，但是，这里指的是请求目的地的域名。比如，通过响应头在浏览器中设置了一个cookie，domain是.a.com，如下三个请求：

网页www.a.com/index.html的前端页面，去请求接口www.b.com/api
网页www.b.com/index.html的前端页面，去请求接口www.a.com/api
网页www.a.com/index.html的前端页面，去请求接口www.a.com/api

只有2、3会带上cookie，因为cookie的取用规则是去看请求的目的地(只看目的，不管来源)，2、3请求的都是www.a.com/api命中domain=.a.com规则。3的这种情况的叫第一方cookie，2的这种情况叫第三方cookie。same-site是cookie的一个属性，它制约第三方cookie的携带(既看目的，也看来源)，其值有三个none、strict、lax。

strict代表完全禁止三方cookie，这是最严格防护，可以避免被CSRF攻击，但缺点也很明显，像天猫、淘宝这种同属一个主体运营的网站不得不重复登录；
none代表完全不做限制，即之前「不认来源，只看目的」的cookie取用原则；
lax则是折中，在某些情况下会限制三方cookie的携带，某些情况又放行，这也是浏览器的默认值（包括safari）。

same-site对很多业务有很大的影响，所以大部分公司目前的解决方案是设置same-site:none并且配合secure。

7. SameParty

same-party可以把.taobao.com、.tmall.com和.alimama.com三个站合起来，它们设置的cookie在这个集合内部不会被当作第三方cookie对待。

首先需要定义First-Party集合：在.taobao.com、.tmall.com和.alimama.com三个站的服务器下都加一个配置文件，放在/.well-know/目录下，命名为first-party-set。其中一个是“组长”，暂定为.taobao.com，在它的的服务器下写入：

// /.well-know/first-party-set
{
  "owner": ".taobao.com",
  "members": [".tmall.com", ".alimama.com"]
}

另外两个是组员：

// /.well-know/first-party-set
{
  "owner": ".taobao.com",
}

并且，在下发cookie时，需要注明same-party属性：

Set-Cookie: id=nian; SameParty; Secure; SameSite=Lax; domain=.taobao.com

这样，我们打开.tmall.com的网站，向.taobao.com发起AJAX请求，都会带上这个cookie，即使当前的same-site属性是lax，因为这集合中的三个域名都会被当作一个站对待，也就是说，在浏览器眼中，这个cookie现在就是第一方cookie。而不在集合中的baidu.com发起的AJAX请求则不会带上。需要注意的是，使用same-party属性时，必须要同时使用https(secure属性)，并且same-site不能是strict。

对三方cookie的限制一是为了浏览器安全，但在国外推动的更重要原因是个人的隐私安全。但不论是出于什么目的，这种改变都会对当前的业务架构造成很大的影响。same-site:lax变成默认是一个暂时的预警，它限制了特定场景下的第三方cookie使用。目前处于比较柔和的过渡期，因为在大部分浏览器中，我们可以简单地将它调整回same-site:none来解除这些限制，和以前一样畅通无阻。但未来这项限制终将无法脱下，same-party才是答案，有了它，我们可以灵活定义哪些站属于业务意义上的“第一方”，哪些才是我们想要的“第三方”。

参考：
https://segmentfault.com/a/1190000041714393?utm_source=sf-hot-article
https://blog.csdn.net/thlzjfefe/article/details/118278542
https://blog.csdn.net/qq_41370833/article/details/125639364