一些网站使用SameSite cookie来防御CSRF攻击。
SameSite属性可用于控制cookie是否以及如何在CSRF中被提交的。通过设置会话cookie的属性，应用程序可以防止浏览器的默认行为，即自动将cookie添加到请求中，而不管请求来自何处。
当服务器发出cookie时，SameSite属性被添加到Set-Cookie响应头中，该属性可以被赋予两个值，Strict或Lax。例如:
Set-Cookie: SessionId=sYMnfCUrAlmqVVZn9dqevxyFpKZt30NN; SameSite=Strict;
Set-Cookie: SessionId=sYMnfCUrAlmqVVZn9dqevxyFpKZt30NN; SameSite=Lax;
如果SameSite属性设置为Strict，那么浏览器将不会在来自其他站点的任何请求中包含cookie。这是最具防御性的选项，但它可能会损害用户体验，因为如果一个已登录的用户跟随第三方链接到某个网站，那么他们就会出现没有登录的情况，在以正常方式与该网站交互之前，需要重新登录。
如果SameSite属性设置为Lax，那么浏览器将在来自另一个站点的请求中包含cookie，但只有在两个条件满足时:
请求使用GET方法。使用其他方法(如POST)的请求将不包括cookie。
该请求来自用户的顶级导航，例如单击链接。其他请求，例如脚本发起的请求，将不包括cookie。
在Lax模式下使用SameSite cookie确实提供了针对CSRF攻击的部分防御，因为作为CSRF攻击目标的用户操作通常是使用POST方法实现的。这里有两个重要的注意事项:
有些应用程序确实使用GET请求实现敏感操作。
许多应用程序和框架都能兼容不同的HTTP方法。在这种情况下，即使应用程序本身设计使用POST方法，它实际上也将接受切换到使用GET方法的请求。
基于上述原因，不建议仅仅依赖SameSite cookie来防御CSRF攻击。然而，与CSRF token一起使用时，SameSite cookie可以提供额外的防御层，这可能会缓解基于 token的防御中的任何缺陷。
