Cookie
Cookies 是可用于向网站添加持久状态的方法之一。多年来，它们的能力不断发展和壮大，但是给平台遗留了一些问题。为了解决这个问题，浏览器（包括 Chrome，Firefox 和 Edge）正在更改其行为，以强制实施更多保留隐私的默认设置。
SameSite
CSRF 的本质实际上是利用了 Cookie 会自动在请求中携带的特性，诱使用户在第三方站点发起请求的行为。除了文中说的一些解决方式之外，标准还专门为 Cookie 增加了 SameSite 属性，用来规避该问题。Chrome 于 2015 年 6 月支持了该属性，Firefox 和 Safari 紧随其后也增加了支持。
本文主要介绍samesite。chrome 51 开始，浏览器的cookie新增了一个samesite属性，用来做一些cookie的限制策略。这个属性可以有三个值:
Strict: 仅允许一方请求携带 Cookie，即浏览器将只发送相同站点请求的 Cookie，即当前网页 URL 与请求目标 URL 完全一致
Lax: 允许部分第三方请求携带 Cookie
None: 无论是否跨站都会发送 Cookie
chrome在2020年2月更新之前默认值为none，chrome80后默认为Lax。
默认值从None变为Lax的区别
Cross site 和 Cross Origin区别
同源策略作为浏览器的安全基石，其「同源」判断是比较严格的，相对而言，Cookie中的「同站」判断就比较宽松：只要两个 URL 的 eTLD+1 相同即可，不需要考虑协议和端口。其中，eTLD 表示有效顶级域名，注册于 Mozilla 维护的公共后缀列表（Public Suffix List）中，例如，.com、.co.uk、.github.io 等。eTLD+1 则表示，有效顶级域名+二级域名，例如 taobao.com 等。
在不同浏览器 samesite的识别也是会不一样
跨站请求时设置了samesite后chrome表现正常，safari却不能正常登录。通过资料发现原来是不同的浏览器对于samesite这个属性具有不一样的行为，以safri为例，在 MacOS 10.14 及 iOS 12 以上版本，safari会把samesite=none识别为samesite=strict，因此会出现a.demoEn.com域名无法登陆的问题，因为获取不到c.demo.com地址的cookie。
服务端做UA判断，检测不兼容的浏览器不设置samesite属性。
遇到的问题：无法获取cookie导致session失效
由于后台是用session存储用户的登录状态的，所以如果这里少了cookie信息的话，由于http本身是无状态的，导致不知道是哪个用户登录了，这里就报了ERROR_SESSION这样的错误，苦思冥想之后，各种搜索，突然发现了一点线索，就是这个 SameSite字段搞得怪。
