02-第三方cookie(注：将被禁用)

简要解释第三方cookie的原理和相关属性。

第三方cookie(即cookie跨站)被告了，2023年将被全面禁止 —!!!注意好这个前提

关于cookie跨站：withCredentials 和 sameSite 属性

【引用一下他处】什么是“同站”：浏览器同源指的是协议，主机名，端口都相同；Cookie中的“同源”只关注域名，忽略协议和端口，也就是Cookie可以跨二级域名来访问，即也可以称为“同站”。

什么是“跨站”：浏览器本身是允许cookie同站通信的；而所谓的“跨站”，比如cookie跨站实现第三方cookie，实际上就是想利用浏览器更加“开放”的那些规则来突破“同站”的限制。

• samesite和withCredentials的对比 【个人思考】
  • withCredentials 和 sameSite属性都是针对cookie跨站的，所以与生俱来就都和CSRF安全相关。
  • 通常需要客户端+服务端一起配合设置
  • 但是针对同样这件事，2者的态度是对立的：一个希望放宽(原有的规则)，一个则希望限制(原有的规则)
  • withCredentials可针对xhr；而samesite可针对xhr，也可包括a img iframe等等标签的引用http所相关的cookie。
  • (withCredentials在很早CORS的时候提出；sameSite在chrome 80中提出，算比较晚了)

---

• withCredentials： 客户端+服务端xhr机制
  • 作用：如果需要跨域(包括“跨站”)AJAX发送Cookie (不仅会发送Cookie，还可以去设置远程主机域名下的Cookie)
  • 基于CORS：为了让这个属性生效，服务器必须显式返回Access-Control-Allow-Credentials这个头信息
    • 备注：Access-Control-Allow-Origin就不能设为星号，要对应上你所允许放行的请求。同时，Cookie依然遵“同站”政策，只有用服务器域名设置的Cookie才会上传，其他域名的Cookie并不会上传
  • 客户端的开启：xhr.withCredentials = true;
    • (反过来看，若未开启时的效果：withCredentials属性是一个布尔值，默认为false。即向“对于example.com是跨域的”请求时，不会发送example.com设置在本机上的Cookie（如果有的话）。)
  • (edge case：如果省略withCredentials设置，有的浏览器还是会一起发送Cookie。这时，可以显式关闭withCredentials。)

---

• 浏览器sameSite属性： 客户端+服务端机制

  • 作用：该属性可分别限制整个页面中的每个http的cookie跨站情况 (即其意图和CSRF相关)
  • 其默认值让 Cookie 在跨站请求时不会被发送，从而可以阻止跨站请求伪造攻击（即CSRF）
  • 出现后所带来的坑：在chrome 80中提出，导致之前上线的旧网站的跨站的Cookie用不了。(其实就是针对和打击第三方Cookie)
    • (而避免CSRF的方式本来就有很多，所以我目前不太认同这种sameSite理念的提出)
  • 旧网站临时解决sameSite默认值所带来的坑：手动设置 SameSite 为 none。

• 注意，在开了withCredentials的环境下，此时客户端你的脚本 还是遵守“cookie同站”政策，无法 从document.cookie或者HTTP回应的头信息之中，读取这些Cookie。

  • (总之，开了之后，可以发送，但仍不能读取跨站cookie)

(将被废弃的)第三方Cookie的实现途径(本质上就是cookie跨站)

• 第三方cookie(即cookie跨站)被告了，2023年将被全面禁止。谷歌的代替品链：
  • 第三方Cookie(废弃) ==> FLoC(还是能确定用户身份，推行受阻) ==> Topics(2022年年初提出)
• 在过渡时期补足，可以使用浏览器指纹，但是效果当然没那么准确
• 以往的被废弃的“第三方Cookie”的实现途径
  • 多数是比如请求ad.com的一张图片，这样在响应这个图片请求的时候就能设置ad.com的cookie
    • (请求图片，本身是完全可以“跨域”和“跨站”的)
  • 有些广告商会封装成一个js，你只要在你的网站引用这个js就帮你实现对应逻辑
  • 但是现在各浏览器的趋势是禁止第三方Cookie。比如浏览器cookie的samesite这个配置，就是限制的态度。