Cookie之SameSite属性

Chrome80之后更新了cookie的携带机制，把原来的SameSite属性，由None改成了Lax，这就导致了一些需要使用到第三方cookie的应用产生了异常。如果你这段时间有经常关注控制台的话，可能会发现一些warning:

Cookie的SameStie属性用来限制第三方Cookie，从而减少安全风险（防止CSRF攻击）和用户追踪。

具体如何使用cookie来防止CSRF攻击，可以参考使用站点Cookie属性防止CSRF攻击，里面基础地介绍了相关的知识。

SameSite属性

SameSite属性用来限制第三方 Cookie，从而减少安全风险，可以设置成三个值：

Strict
Lax
None

1.Strict

Set-Cookie: CookieName=CookieValue; SameSite=Strict;

Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。这个规则过于严格，可能造成非常不好的用户体验。比如，当前网页有一个 GitHub 链接，用户点击跳转就不会带有 GitHub 的 Cookie，跳转过去总是未登陆状态。

2.Lax

Set-Cookie: CookieName=CookieValue; SameSite=Lax;

Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。导航到目标网址的 GET 请求，只包括三种情况：链接，预加载请求，GET 表单

请求类型	示例	以前	Strict	Lax	None
链接	`<a href="..."></a>`	发送Cookie	不发送	发送Cookie	发送Cookie
预加载	`<link rel="prerender" href="..."/>`	发送Cookie	不发送	发送Cookie	发送Cookie
get表单	`<form method="GET" action="...">`	发送Cookie	不发送	发送Cookie	发送Cookie
post表单	`<form method="POST" action="...">`	发送Cookie	不发送	不发送	发送Cookie
iframe	`<iframe src="..."></iframe>`	发送Cookie	不发送	不发送	发送Cookie
ajax	`$.get("...")`	发送Cookie	不发送	不发送	发送Cookie
image	`<img src="...">`	发送Cookie	不发送	不发送	发送Cookie

从上面的表格可以看出，将SameSite的值从None改为Lax后，Form,Iframe,Ajax和Image中跨站的请求受到的影响最大。解决办法也很简单，就是接下来介绍的None值。

3.None

Set-Cookie: widget_session=abc123; SameSite=None; Secure;

Chrome 计划将Lax变为默认设置。这时，网站可以选择显式关闭SameSite属性，将其设为None。不过，前提是必须同时设置Secure属性（Cookie 只能通过 HTTPS 协议发送），否则无效。

部分浏览器不能加SameSite=none，比如一些老版本的chrome浏览器等，它们会错误的把SameSite=none识别成SameSite=strict。因此后端要根据UA来判断是否加上SameSite=none。
不支持SameSite = none的浏览器版本等具体情况，可参照链接

Cookie之SameSite属性