我们正在将 Cookie 的 **SameSite** 属性的默认值从 **None** 更改为 **Lax**。这将大大提高用户的安全性。但是，一些网站可能（甚至不知情地）依赖于旧的默认值，这可能会导致这些网站出现故障。在 Mozilla，我们正在缓慢地引入这种更改。我们强烈建议所有 Web 开发人员使用新的默认值测试他们的网站。

背景

SameSite 是 Cookie 上的一个属性，它允许 Web 开发人员声明 Cookie 应该被限制在第一方或同站点上下文中。该属性可以具有以下任何值

• None – 浏览器将在跨站点和同站点请求中都发送 Cookie。
• Strict – 浏览器只会为同站点请求发送 Cookie（即，来自设置 Cookie 的网站的请求）。
• Lax – Cookie 将在跨站点请求（例如，调用加载图像或框架）上被阻止。但是，当用户从外部网站（例如，通过点击链接）导航到 URL 时，Cookie 将被发送。

目前，没有 **SameSite** 属性意味着 Cookie 将附加到给定来源的任何请求，无论是谁发起该请求。此行为等同于设置 **SameSite=None**。但是，这种“默认打开”行为让用户容易受到跨站点请求伪造 (CSRF) 攻击。在 CSRF 攻击中，恶意网站试图使用来自合法网站的有效 Cookie 来执行攻击。

使网络更安全

为了保护用户免受 CSRF 攻击，浏览器需要更改处理 Cookie 的方式。主要更改有两个：

• 未指定时，Cookie 默认将被视为 **SameSite=Lax**
• 明确设置 **SameSite=None** 以启用跨站点传递的 Cookie 还必须设置 **Secure** 属性。（换句话说，它们必须要求 HTTPS。）

依赖于旧默认行为的网站现在必须明确将 **SameSite** 属性设置为 **None**。此外，它们需要包含 **Secure** 属性。一旦此更改在 Firefox 内部完成，如果网站未能正确设置 **SameSite**，则这些网站可能会对用户造成故障。

引入更改

新的 **SameSite** 行为自 Nightly 75（2020 年 2 月）以来一直是 Firefox Nightly 的默认行为。在 Mozilla，我们能够探索这种更改的影响。从 Firefox 79（2020 年 6 月）开始，我们将其推广到 Firefox Beta 用户群体的 50%。我们想监控任何潜在故障的范围。

目前还没有将此功能发布到 Firefox 发布通道的时间表。我们希望看到 Beta 用户群没有出现不可接受的网站故障——表明大多数网站已经适应了新的默认行为。由于没有对“故障”的精确定义，并且可能难以通过遥测来确定，因此我们正在关注多个渠道（例如 Bugzilla、社交媒体、博客）中出现的网站故障报告。

此外，我们希望看到提案在 IETF 中取得进一步进展。作为开放网络的支持者，对 Web 生态系统的更改进行适当的标准化非常重要。

行业协调

这是浏览器范围的行业级更改，并非 Mozilla 单独进行。自 2020 年 2 月以来，谷歌一直在 向 Chrome 用户推广此更改，其中 **SameSite=Lax** 是其所有通道（发布、测试版、金丝雀版）的特定（未发布）百分比的默认值。

Mozilla 正在与谷歌合作，跟踪和共享我们各自的错误跟踪数据库中网站故障的报告。我们共同鼓励所有 Web 开发人员将明确设置 **SameSite** 属性作为最佳实践。

• Firefox 故障跟踪器
• Chrome 故障跟踪器

对 Web 开发者的号召

在 Firefox Nightly 和 Beta 通道中的测试表明确实存在网站故障。虽然我们已经联系了遇到的这些网站，并鼓励他们在其 Web 属性上设置 **SameSite** 属性，但 Web 的规模显然太大，无法逐个进行。

所有 Web 开发人员都应该根据这种新的默认值测试他们的网站。这将为 Firefox 和 Chrome 浏览器在其各自的发布通道中进行切换做好准备。

在 Firefox 中测试您的网站

要在 Firefox 中测试

1. 启用新的默认行为（适用于 75 版之后的任何版本）
   1. 在 URL 栏中，导航到 **about:config**。（接受警告提示，如果出现）。
   2. 在“搜索首选项名称”栏中输入 **SameSite**。
   3. 使用切换图标将 **network.cookie.sameSite.laxByDefault** 设置为 **true**。
   4. 使用切换图标将 **network.cookie.sameSite.noneRequiresSecure** 设置为 **true**。
   5. 重新启动 Firefox。
2. 验证浏览器是否使用新的 SameSite 默认行为
   1. 导航到 https://samesite-sandbox.glitch.me/.
   2. 验证所有行是否为绿色。

此时，彻底测试您的网站。特别要注意涉及登录流程、多个域或跨站点嵌入式内容（图像、视频等）的任何内容。对于涉及 POST 请求的任何流程，您应该使用和不使用长时间延迟进行测试。这是因为 Firefox 和 Chrome 都实现了 2 分钟的阈值，允许在顶级跨站点 **POST** 请求（常见的登录流程）中发送没有 **SameSite** 属性的全新创建的 Cookie。

检查您的网站是否存在故障

要查看您的网站是否受到新的 Cookie 行为的影响，请检查 Firefox Web 控制台 并查找以下两条消息

• Cookie 被拒绝，因为它具有“sameSite=none”属性，但缺少“secure”属性。
• Cookie 的“sameSite”策略设置为“lax”，因为它缺少“sameSite”属性，并且“sameSite=lax”是此属性的默认值。

看到任何这些消息并不一定意味着您的网站将不再正常工作，因为新的 Cookie 行为可能对您网站的功能并不重要。因此，重要的是每个网站都在新条件下进行测试。然后，验证新的 **SameSite** 行为不会破坏任何内容。作为一般规则，明确设置 Cookie 的 **SameSite** 属性是保证您的网站继续以可预测的方式运行的最佳方式。

其他资源

SameSite Cookie 解释

SameSite Cookie – 您准备好了吗？

MDN – SameSite Cookie 和常见警告

跟踪 Chrome 对 SameSite 更改的推广