由于 HTTP 协议是无状况的，所以很久以前的网站是没有登录这个概念的，直到网景创造 cookie 今后，网站才开端运用 cookie 记载用户的登录状况。cookie 是个好东西，但它很不安全，其间一个原因是由于 cookie 开始被规划成了答应在第三方网站建议的恳求中带着，CSRF 进犯便是运用了 cookie 的这一“缺点”，假设你不了解 CSRF，请移步其他当地学习一下再来。

当咱们在浏览器中翻开 *** 站点下的一个网页后，这个页面后续能够建议其它的 HTTP 恳求，依据恳求顺便的体现不同，这些恳求能够分为两大类：

1. 异步恳求（不会改动当时页面，也不会翻开新页面），比方经过 <script>、<link>、<img>、<iframe> 等标签建议的恳求，还有经过各种发送 HTTP 恳求的 DOM API（XHR，fetch，sendBeacon）建议的恳求。

2. 同步恳求（或许改动当时页面，也或许翻开新页面），比方经过对 <a> 的点击，对 <form> 的提交，还有改动 location.href，调用 window.open() 等 *** 发生的恳求。

上面说的同步和异步并不是正式术语，仅仅我个人的一种差异 *** 。

这些由当时页面建议的恳求的 URL 不一定也是 *** 上的，或许有 b.com 的，也或许有 c.com 的。咱们把发送给 *** 上的恳求叫做榜首方恳求（first-party request），发送给 b.com 和 c.com 等的恳求叫做第三方恳求（third-party request）， 第三方恳求和榜首方恳求相同，都会带上各自域名下的 cookie ，所以就有了榜首方 cookie（first-party cookie）和第三方 cookie（third-party cookie）的差异。上面说到的 CSRF 进犯，便是运用了第三方 cookie 。

避免 CSRF 进犯的 *** 现已有 CSRF token 校验和 Referer 恳求头校验。为了从源头上处理这个问题，Google 起草了 一份草案 来改善 HTTP 协议，那便是为 Set-Cookie 呼应头新增 SameSite 特点，它用来标明这个 cookie 是个“同站 cookie”，同站 cookie 只能作为榜首方 cookie，不能作为第三方 cookie。SameSite 有两个特点值，别离是 Strict 和 Lax，下面别离解说：

SameSite=Strict：

严厉方式，标明这个 cookie 在任何情况下都不或许作为第三方 cookie，绝无破例。比方说假设 b.com 设置了如下 cookie：

Set-Cookie: foo=1; SameSite=Strict
Set-Cookie: bar=2

你在 *** 下建议的对 b.com 的恣意恳求中，foo 这个 cookie 都不会被包含在 Cookie 恳求头中，但 bar 会。举个实践的比方便是，假设 *** 网站用来辨认用户登录与否的 cookie 被设置成了 SameSite=Strict，那么用户从百度搜索页面乃至天猫页面的链接点击进入 *** 后， *** 都不会是登录状况，由于 *** 的服务器不会接受到那个 cookie，其它网站建议的对 *** 的恣意恳求都不会带上那个 cookie。

SameSite=Lax：

宽松方式，比 Strict 放宽了点约束：假设这个恳求是我上面总结的那种同步恳求（改动了当时页面或许翻开了新页面）且一起是个 GET 恳求（由于从语义上说 GET 是读取操作，比 POST 更安全），则这个 cookie 能够作为第三方 cookie。比方说假设 b.com 设置了如下 cookie：

Set-Cookie: foo=1; SameSite=Strict
Set-Cookie: bar=2; SameSite=Lax
Set-Cookie: baz=3

当用户从 *** 点击链接进入 b.com 时，foo 这个 cookie 不会被包含在 Cookie 恳求头中，但 bar 和 baz 会，也便是说用户在不同网站之间经过链接跳转是不受影响了。但假设这个恳求是从 *** 建议的对 b.com 的异步恳求，或许页面跳转是经过表单的 post 提交触发的，则 bar 也不会发送。

该用哪种方式？

该用哪种方式，要看你的需求。比方你的网站是一个少数人运用的后台办理体系，所有人的操作 *** 都是从自己浏览器的保藏夹里翻开网址，那我看用 Strict 也不妨。假设你的网站是微博，用了 Strict 会这样：有人在某个论坛里发了帖子“快看这个微博多搞笑 http://weibo.com/111111/aaaaaa”，成果下面人都回复“打不开啊”；假设你的网站是 *** ，用了 Strict 会这样：某微商在微博上发了条音讯“新百伦正品特卖5折起 https://item.taobao.com/item.htm?id=1111111”，成果点进去顾客买不了，也便是说，这种超多用户的、或许常常需求用户从其他网站点过来的网站，就不适合用 Strict 了。

假设你的网站有用 iframe 方式嵌在其他网站里的需求，那么连 Lax 你也不能用，由于 iframe 恳求也是一种异步恳求。或许假设其他网站有运用你的网站的 *** ONP 接口，那么相同 Lax 你也不能用，比方天猫便是经过 *** 的 *** ONP 接口来判别用户是否登录的。

有时安全性和灵活性便是对立的，需求取舍。

和浏览器的“禁用第三方 cookie”功用有什么差异？

干流浏览器都有禁用第三方 cookie 的功用，它和 SameSite 有什么差异？我能总结 3 点：

1. 该功用是由用户决议是否敞开的，是针对整个浏览器中所有 cookie 的，即使有些浏览器能够设置域名白名单，那最小单位也是域名；而 SameSite 是由网站决议是否敞开的，它针对的是某个网站下的单个 cookie。

2. 该功用一起禁用第三方 cookie 的读和写，比方 *** 建议了对 b.com 的恳求，这个恳求彻底不会有 Cookie 恳求头，一起假设这个恳求的呼应头里有 Set-Cookie: foo=1，foo 这个 cookie 也不会被写进浏览器里；而 SameSite 只禁用读，比方 b.com 在用户浏览器下现已写入了个 SameSite cookie foo，当 *** 恳求 b.com 时，foo 必定不会被发送过去，但 b.com 在这个恳求的呼应里又返回了： Set-Cookie: bar=1; SameSite=Strcit，这个 bar 会成功写入浏览器的 cookie 里。

3. 该功用不会把我上面说的那种同步恳求（改动了当时页面或许翻开了新页面）算在第三方恳求里，因而也不会阻拦对应的 cookie。

究竟怎样才算第三方恳求？

我上面说的原话是：当一个恳求自身的 URL 和它的建议页面的 URL 不归于同一个站点时，这个恳求就算第三方恳求。那么怎样算是同一个站点？是咱们常常说的同源（same-origin）吗，cross-origin 的两个恳求就不归于同一个站点？明显不是的，foo. *** 和 bar. *** 是不同源的，但很有或许是同一个站点的， *** 和 *** :8000 是不同源的，但它俩肯定是归于同一个站点的，浏览器在判别第三方恳求时用的判别逻辑并不是同源战略，而是用了 Public Suffix List 来判别。

[1] [2]  黑客接单网