首先，来自Chrome的定义：

同站点 cookie（née “First-Party-Only”（née “First-Party”））允许服务器通过断言特定 cookie 仅应与从同一站点发起的请求一起发送来降低 CSRF 和信息泄露攻击的风险可注册的域。

那么这可以防止什么？

CSRF？

同站cookies可以有效防止CSRF攻击。为什么？

如果您将会话 cookie 设置为同一站点，则只有在您的站点发出请求时才会发送它。http://malicious.com因此，攻击者将受害者引诱到发布请求的站点的标准 CSRF 攻击http://bank.com/transfer.php?amount=10000&receiver=evil_hacker将不起作用。由于malicious.com与 不是同一个站点bank.com，因此浏览器不会发送会话 cookie，并且transfer.php会像受害者未登录一样执行。

这与设置 HTTP 标头如何保护您免受 CSRF 的影响非常相似X-Csrf-Token——同样，只有当请求来自您的域时才会发送某些内容。same-site 属性将您的会话 cookie 转换为 CSRF 令牌。

那么问题解决了吗？嗯，有点。有一些警告：

• 这仅适用于实现此功能的浏览器。到目前为止，很少有人这样做。除非你想把所有使用稍微旧一点的浏览器的人都扔到车下，否则你仍然需要实现一个老式的 CSRF 令牌。
• 如果您需要更细粒度的控制，这还不够。如果您运行的系统显示不受信任的用户内容，例如论坛，您不希望来自用户帖子的请求被视为有效。如果有人向http://myforum.com/?action=delete_everything您发布链接，则不希望仅仅因为用户单击它而删除任何内容。使用传统的 CSRF 令牌，您可以准确控制何时使用它。使用同站点 cookie，您不能。
• 与老式 CSRF 保护相同的旧警告仍然适用。如果你有 XSS 漏洞，这个世界上没有任何 CSRF 保护可以拯救你。

话虽如此，同站点cookie仍然是一件好事，应该与传统防御一起使用作为纵深防御。

XSS 和 XSSI？

同站点 cookie 无法保护您免受普通 XSS 攻击。如果黑客设法欺骗您的网站以从您网站的 URL 中回显脚本，它将作为来自您的来源（毕竟，它是）执行，因此会话 cookie 仍将与注入脚本的所有请求一起发送使您的域。

如果您仔细阅读帖子中的引文，您会看到它说的是 XSSI，末尾带有 I，而不是 XSS。I 代表包含，XSSI 与 XSS 相关但不同。这是对 XSSI 以及它与 XSS 的区别的一个很好的解释：

XSSI 是 XSS 的一种形式，它利用浏览器不会阻止网页包含托管在其他域和服务器上的图像和脚本等资源这一事实。[...] 例如，如果银行 ABC 的网站有一个脚本可以读取用户的私人账户信息，黑客可以将该脚本包含在他们自己的恶意站点 ( www.fraudulentbank.com ) 中，以便在任何时候从银行 ABC 的服务器中提取信息。 ABC 银行的客户访问了黑客的网站。

同站点 cookie 可以保护您免受 XSSI 的影响，因为会话 cookie 不会随脚本请求一起发送，因此不会返回任何敏感信息。但是，对于普通的 XSS 来说并没有什么区别。

这取决于您想要支持的浏览器以及您的网站当前的设置方式。

如果您只严格支持支持该功能的浏览器，那么只要您愿意，就足够了：

• 不发送带有顶级导航的 cookie（这是非常严格的，因为您无法从外部链接到登录页面）
• 确保不使用任何操作GET（或任何安全方法）来执行操作，否则您会像上一个答案一样打开自己的链接攻击

如果您可以在没有顶级导航的情况下从外部站点登录页面，那么SameSite: 'strict'可能是合适的，此选项使给定的 cookie 不会与任何跨域请求（包括单击链接等）一起发送。

如果您需要从外部站点链接到登录页面，那么您需要确保从（或任何安全方法）到服务器不会发生可观察到的更改，并且应该使用。如果您可以确保此约束，那么即使是用户提交的链接也应该是安全的（无论如何都不会受到 CRSF 攻击）。GETSameSite: 'lax'

确保这些约束中的任何一个在现有代码库中都可能不是微不足道的（除了现代浏览器的要求），所以如果你已经在使用它们，我不建议删除 CSRF 令牌，因为很多地方仍然滥用GET触发操作。

如果您正在开始一个新项目并且不打算支持任何不支持该功能的浏览器，则可能值得考虑，因为它基本上只是一行代码，只需确保您了解'lax'和'strict'模式以及您需要遵循的限制。

关于SameSite: 'strict'：如果您正在使用SameSite: 'strict'并且用户单击外部链接进入站点的受限部分，则可能会显示一个启动屏幕，询问他们是否要继续。如果资源不打算与外部链接，我强烈建议这样做，在这种情况下，链接可能是攻击/技巧。

如果用户确实选择继续，则通过这样的启动屏幕，他们仍然不需要再次登录，因为在您的网站上单击继续将发送SameSite-cookies，因为它确实是同一来源。

如果您希望重定向自动发生，您也可以Refresh: 0为您知道安全的页面添加标题（这也是检查给定页面是否实际上可以安全地进行外部链接的好机会，如果不回退到启动上面提到的屏幕）。这个 vs 的主要缺点SameSite: 'lax'是你最终会重复导航两次。