category
警告：浏览器正在限制第三方cookie的使用。如果您过去在cookie上设置了SameSite=None，则需要采取其他操作。了解如何准备第三方cookie限制。
注意：此页面是SameSite cookie属性更改系列的一部分，其中包括以下内容：
- 了解Cookie
- SameSite饼干配方
- 有计划的相同站点
每个cookie都包含一个键值对以及控制cookie何时何地使用的许多属性。
SameSite属性（在RFC6265bis中定义）的引入允许您声明您的cookie是限于第一方还是同一站点上下文。准确理解“site”在这里的含义是很有帮助的。该站点是域后缀和其前面的域部分的组合。例如，www.web.dev域是web.dev站点的一部分。
关键术语：如果用户在www.web.dev上，并从static.web.dev请求图像，则是同一个网站请求。
公共后缀列表定义在同一网站上的页面计数。它不仅依赖于.com等顶级域，还可以包括github.io等服务。这使您的project.github.io和my-project.githubio可以算作独立的网站。
关键术语：如果用户在你的project.github.io上，并从my-project.githubio请求图像，这是一个跨站点请求。
使用SameSite属性声明cookie使用情况
cookie上的SameSite属性提供了三种不同的方式来控制这种行为。您可以选择不指定属性，也可以使用Strict或Lax将cookie限制为相同的网站请求。
如果您将SameSite设置为Strict，则cookie只能在第一方上下文中发送；也就是说，如果cookie的站点与浏览器地址栏中显示的站点匹配。因此，如果promo_shown cookie设置如下：
Set-Cookie: promo_shown=1; SameSite=Strict
当用户在您的网站上时，cookie会按预期随请求一起发送。然而，如果用户从另一个链接进入你的网站，cookie不会在最初的请求中发送。这对于与初始导航（如更改密码或购买）后面的功能相关的cookie来说是好的，但对于类似promo_shown的cookie来说，这太过限制。如果你的读者按照链接进入网站，他们希望发送cookie，以便应用他们的偏好。
SameSite=Lax允许浏览器发送带有这些顶级导航的cookie。例如，如果另一个网站引用了你的网站内容，在这种情况下，使用你的猫照片并提供一个链接到你的文章，如下所示：
<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>
将cookie设置为Lax，如下所示：
Set-Cookie: promo_shown=1; SameSite=Lax
当浏览器为他人的博客请求amazingcat.png时，你的网站不会发送cookie。然而，当读者在您的网站上点击cat.html的链接时，该请求确实包括cookie。
我们建议以这种方式使用SameSite，将影响网站显示的cookie设置为Lax，将与用户操作相关的cookie设置成Strict。
注意：无论是Strict还是Lax都不是网站安全的完整解决方案。Cookie是作为用户请求的一部分发送的，您应该以与任何其他用户输入相同的方式对其进行消毒和验证。永远不要使用cookie来存储您认为是服务器端机密的数据。
您也可以将SameSite设置为None，表示希望在所有上下文中发送cookie。如果您提供其他网站使用的服务，如小工具、嵌入内容、附属程序、广告或跨多个网站登录，请使用“无”以确保您的意图明确。
三个cookie根据上下文标记为None、Lax或Strict
将cookie的上下文明确标记为None、Lax或Strict。
在没有SameSite的情况下更改默认行为
浏览器支持
SameSite属性得到了广泛支持，但尚未被广泛采用。过去，在没有SameSite的情况下设置cookie默认为在所有上下文中发送，这使得用户容易受到CSRF和无意信息泄露的影响。为了鼓励开发人员陈述他们的意图，并为用户提供更安全的体验，IETF的提案“增量更好的Cookie”列出了两个关键变化：
- 没有SameSite属性的Cookie被视为SameSite=Lax。
- SameSite=None的Cookie还必须指定Secure，这意味着它们需要一个安全的上下文。
这两项更改都向后兼容已正确实现SameSite属性先前版本的浏览器，以及不支持SameSite早期版本的浏览器。它们旨在通过明确cookie行为和预期用途来减少开发人员对浏览器默认行为的依赖。任何不识别SameSite=None的客户端都应该忽略它。
SameSite=Lax by default
如果发送cookie时未指定其SameSite属性，则浏览器会将该cookie视为设置为SameSite=Lax。我们仍然建议明确设置SameSite=Lax，以使您的用户体验在浏览器之间更加一致。
注意：Chrome的默认行为比显式SameSite=Lax稍微宽松一些，因为它允许网站在顶级POST请求中发送一些cookie。有关详细信息，请参阅blink dev公告。这是一种临时缓解措施。您仍然需要将跨站点cookie更新为SameSite=None；按照下一节中的说明进行固定。
SameSite=None must be secure
当您使用SameSite=None创建跨站点cookie时，您还必须将其设置为“安全”，浏览器才能接受它们：
Set-Cookie: widget_session=abc123; SameSite=None; Secure
您可以通过启用about://flags/#cookies-没有相同站点必须是安全的，并且从Firefox 69通过在about:config中设置network.cookie.sameSite.noneRequiresSecure。
我们还建议尽快将现有cookie更新为安全cookie。如果您依赖在您的网站上提供第三方内容的服务，请确保您的服务提供商更新其cookie，并更新您网站上的任何片段或依赖项，以确保其使用新的行为。
警告：一些早期版本的浏览器，包括Chrome、Safari和UC浏览器，与新的None属性不兼容，可能会忽略或限制cookie。这种行为在当前版本中是固定的，但我们建议检查您的流量，以确定受影响的用户比例。您可以在Chromium网站上看到已知不兼容客户端的列表。
SameSite cookie配方
有关更新cookie以成功处理SameSite=None的这些更改以及浏览器行为差异的更多详细信息，请参阅后续文章SameSite cookie配方。
衷心感谢Lily Chen、Malte Ubl、Mike West、Rob Dodson、Tom Steiner和Vivek Sekhar的贡献和反馈。
- 登录 发表评论