最近我了解了用于缓解 CSRF 攻击的 SameSite cookie 属性。AFAIK SameSite cookie 属性在 Chrome 和其他一些浏览器中实现。由于我正在使用 Tomcat 服务器来部署我的 Web 应用程序，因此我与 Tomcat 开发人员进行了讨论，以了解他们是否计划在即将发布的版本中支持此功能。他们说如果规范工作没有停止和/或它提供的保护更完整，那么他们可以考虑支持 SameSite Cookie。在这里，我想澄清下面提到的问题。
[1] [ https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-02.txt]
SameSite cookie 将继续存在。
它们在 Chrome 中可用很长时间（自 v51 起），最近在 Firefox中实现。
使 cookie 同站点可防止各种 CSRF 漏洞。它可以防止 BREACH，这是一种压缩侧通道攻击，可以通过伪造大量经过身份验证的请求来窃取 cookie。它可以防止某些客户端 Spectre 攻击，其中使用推测执行漏洞读取对跨域请求的响应。
该规范仍在制定中。例如，在重定向中，同站点 cookie 的行为应该如何严格尚不完全清楚。
我目前建议大家在所有 cookie 上设置 samesite=Lax。它提供了一个合理的安全优势，而不会破坏东西或做太多的工作。使用 samesite=Strict cookie 可提供更高的安全性，但可能会破坏您网站上的某些功能。
服务器软件需要提供将 samesite 属性设置为Lax或的选项Strict。规范的那部分非常稳定，现在提供它还为时过早。例如，PHP计划将 samesite 添加到他们的 setcookie 函数中。
另外，如果您创建自己的 Set-Cookie 标头，我希望您可以使用相同站点的 cookie，即使 Tomcat 没有实现它。
更新：Chrome 计划默认设置所有 cookie SameSite=Lax，您可以通过设置 SameSite=None 来禁用它。
为@Sjoerd 答案添加更多内容。
据我所知，SameSite cookie 不能protect against a whole range of CSRF vulnerabilities。如果网站有 GET 基础 CSRF 漏洞，攻击者仍然可以轻松利用它，但 SameSite cookie 可以很好地对抗 POST 基础 CSRF。
此外，它还可以防止许多侧通道攻击，这些攻击使用 cookie 跨站点发送请求并测量不同的时间。