因此，对于Google Chrome和Opera，Cookie具有SameSite属性，该属性可以包含以下两个值之一：strict或lax。
这些之间的一些差异是SameSite=strict会阻止在我们点击指向其他域的链接时发送Cookie。
我知道SameSite尚未推荐W3C，但这种行为的潜在好处是什么？我觉得它很烦人，因为当我们刷新或点击当前域上的另一个链接时，无论如何都会发送cookie。这导致了相当奇怪的用户体验 - 例如：我们已经注销，然后我们点击一些国内链接或刷新，我们突然被认证。
我知道它不是为最佳用户体验而设计的，而是为安全性而设计的。但是我们在安全方面实际上赢得了什么？
答案 0 :(得分：1)
使用strict代替lax的好处是有限的。我可以看到两个：
通过GET请求对CSRF攻击的防护。这种攻击通常是不可能的，因为它们依赖服务器来实现GET终结点，这些终结点具有副作用（不正确且违反RFC 7231指定的语义）。您在评论中给出了一个示例：
想象一下，我们的设计非常糟糕，我们所有的操作都在GET方法上执行。攻击者放置了链接，说“保存小狗”，该链接链接到
http://oursite.com/users/2981/delete。这是我能想到的唯一用例-当我们通过GET方法执行了一些操作时，却不是。
保护定时攻击。有一类攻击-已被back in 2000发现，但最近Mathias Bynens已被探索和流行-涉及一种使用JavaScript的恶意网页向另一个域上的页面发起请求，然后衡量其攻击方式。需要花费很长时间，并且可以从花费的时间推断出有关用户的信息。 Mathias发明的一个示例是使用restricted audience向Facebook页面发起请求，这样，例如Exampletan中的人们只能访问该请求。然后，邪恶的网页乘以响应返回所需的时间。当您尝试访问无法访问的帖子的速度比实际帖子的访问速度快时，Facebook会提供错误页面，因此，如果恶意网页得到快速响应，则可以推断出该用户不在Examplestan中；如果收到 slow 响应，则用户可能是“示例”。
由于浏览器在您进行顶级导航时不会停止在页面上执行JavaScript，直到它们从被导航到的URL接收到响应后，不幸的是，对于这些计时攻击，使用顶级导航完全可以实现；您的恶意页面只能通过location=whatever引导用户离开，然后通过将当前时间戳重复记录到localStorage中来确定另一页面加载所需的时间。然后，在随后的访问中，恶意页面可以检查该页面开始卸载所需的时间，并推断出该页面的响应时间。
托管目标页面的域（例如Mathias的例子，例如facebook.com）可以使用samesite=strict cookie来保护其用户免受此类攻击。
显然，这些有限的好处是在UX折衷的情况下进行的，因此与samesite=lax提供的已经非常好的保护相比，这通常是不值得的！
答案 1 :(得分：0)
这里应该有一个答案，所以我只想重复评论中已经说过的内容。
您应该始终使用samesite=lax，除非您为用户提供糟糕的用户体验。 lax足够安全，因为Cookie只会在从其他域引用时发送Safe Methods（即GET）。如果你对GET请求做了危险的事情，那么你就会遇到更大的问题。