Cookie之SameSite属性

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
链接		发送Cookie	不发送	发送Cookie	发送Cookie
预加载		发送Cookie	不发送	发送Cookie	发送Cookie
get表单		发送Cookie	不发送	发送Cookie	发送Cookie
post表单		发送Cookie	不发送	不发送	发送Cookie
iframe		发送Cookie	不发送	不发送	发送Cookie
ajax	$.get("...")	发送Cookie	不发送	不发送	发送Cookie
image		发送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的浏览器版本等具体情况，可参照链接

参考

• http://www.ruanyifeng.com/blo...
• https://web.dev/samesite-cook...
• https://web.dev/samesite-cook...
• RFC文档：https://tools.ietf.org/html/d...