Cookie最初被设计成了允许在第三方网站发起的请求中携带，CSRF 攻击就是利用了Cookie的这一“弱点”，防止 CSRF 攻击的办法已经有 CSRF token 校验和Referer请求头校验。为了从源头上解决这个问题，Google起草了一份草案来改进HTTP协议，那就是为Set-Cookie响应头新增SameSite属性，它用来标明这个Cookie是个“同站Cookie”，同站Cookie只能作为第一方Cookie，不能作为第三方 cookie。

Chrome 51开始，浏览器的Cookie新增加了一个SameSite属性，用来防止CSRF攻击和用户追踪。

SameSite 属性

Cookie 的SameSite属性用来限制第三方 Cookie，从而减少安全风险。

它可以设置三个值。

  • Strict
  • Lax
  • None

Strict

Strict最为严格，完全禁止第三方 Cookie，跨站点时，任何情况下都不会发送 Cookie。换言之，只有当前网页的 URL 与请求目标一致，才会带上 Cookie。

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

这个规则过于严格，可能造成非常不好的用户体验。比如，当前网页有一个 GitHub 链接，用户点击跳转就不会带有 GitHub 的 Cookie，跳转过去总是未登陆状态。

Lax

Lax规则稍稍放宽，大多数情况也是不发送第三方 Cookie，但是导航到目标网址的 Get 请求除外。

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

导航到目标网址的 GET 请求，只包括三种情况：链接，预加载请求，GET 表单。详见下表。

请求类型 示例 正常情况 Lax
链接 <a href="..."></a> 发送 Cookie 发送 Cookie
预加载 <link rel="prerender" href="..."/> 发送 Cookie 发送 Cookie
GET 表单 <form method="GET" action="..."> 发送 Cookie 发送 Cookie
POST 表单 <form method="POST" action="..."> 发送 Cookie 不发送
iframe <iframe src="..."></iframe> 发送 Cookie 不发送
AJAX $.get("...") 发送 Cookie 不发送
Image <img src="..."> 发送 Cookie 不发送

设置了Strict或Lax以后，基本就杜绝了 CSRF 攻击。当然，前提是用户浏览器支持 SameSite 属性。

None

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

下面的设置无效。

Set-Cookie: widget_session=abc123; SameSite=None

下面的设置有效。

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

Chrome的SameSite设置

chrome 91已经从chrome://flags中移除#same-site-by-default-cookies和 #cookies-without-same-site-must-be-secure配置项，chrome 94会移除命令行配置项--disable-features=SameSiteByDefaultCookies,CookiesWithoutSameSiteMustBeSecure

Firefox的SameSite设置

在Firefox 75以上版本打开about:config搜索首选项SameSite，设置network.cookie.sameSite.laxByDefault和network.cookie.sameSite.noneRequiresSecure为true，重启浏览器。