Schemeful Same-Site

“同网站”的定义正在不断演变，现在已包含网址架构，因此网站的 HTTP 版本和 HTTPS 版本之间的链接现在被视为跨网站请求。请默认升级到 HTTPS，以尽可能避免出现问题，或继续阅读以了解需要哪些 SameSite 属性值。

Steven Bingler

Rowan Merewood

Schemeful Same-Site 将（网络）网站的定义从仅可注册网域修改为 架构 + 可注册网域。如需了解更多详情和示例，请参阅 了解“同网站”和“同源”。

好消息是：如果您的网站已完全升级到 HTTPS，则无需担心任何问题。对您没有任何影响。

如果您尚未完全升级网站，则应优先升级。 不过，如果您的网站访问者会在 HTTP 和 HTTPS 之间切换，那么本文稍后会介绍一些常见情况以及相关的 SameSite Cookie 行为。

您可以在 Chrome 和 Firefox 中启用这些更改以进行测试。

• 从 Chrome 86 开始，启用 about://flags/#schemeful-same-site。在 Chrome 状态 页面上跟踪进度 。
• 从 Firefox 79 开始，通过 about:config 将 network.cookie.sameSite.schemeful 设置为 true。使用 Bugzilla 问题跟踪进度。

将 Cookie 的默认值更改为 SameSite=Lax 的主要原因之一是为了防范 跨站请求伪造 (CSRF)。不过，不安全的 HTTP 流量仍然为网络攻击者提供了篡改 Cookie 的机会，这些 Cookie 随后将在网站的安全 HTTPS 版本中使用。在架构之间创建此额外的跨网站边界可以进一步防御这些攻击。

常见的跨架构情况

导航

以前，在网站的跨架构版本之间导航（例如，从 http://site.example 链接到 https://site.example）会允许发送 SameSite=Strict Cookie。现在，这被视为跨网站导航，这意味着 SameSite=Strict Cookie 将被屏蔽。

加载子资源

在您努力升级到完全 HTTPS 的过程中，您在此处所做的任何更改都应仅被视为临时修复。

子资源的示例包括图片、iframe 以及使用 XHR 或 Fetch 发出的网络请求。

以前，在网页上加载跨架构子资源会允许发送或设置 SameSite=Strict 或 SameSite=Lax Cookie。现在，这与其他任何第三方或跨网站子资源的处理方式相同，这意味着任何 SameSite=Strict 或 SameSite=Lax Cookie 都将被屏蔽。

此外，即使浏览器允许在安全网页上加载来自不安全架构的资源，所有 Cookie 也都会在这些请求中被屏蔽，因为第三方或跨网站 Cookie 需要 Secure。

发布表单

以前，在网站的跨架构版本之间发布内容会允许发送使用 SameSite=Lax 或 SameSite=Strict 设置的 Cookie。现在，这被视为跨网站 POST，只有 SameSite=None Cookie 可以发送。您可能会在默认显示不安全版本的网站上遇到这种情况，但在提交登录或结账表单时，这些网站会将用户升级到安全版本。

与子资源一样，如果请求来自安全环境（例如 HTTPS）到不安全环境（例如 HTTP），那么所有 Cookie 都会在这些请求中被屏蔽，因为第三方或跨网站 Cookie 需要 Secure。

如何测试我的网站？

Chrome 和 Firefox 中提供了开发者工具和消息。

从 Chrome 86 开始，DevTools 中的“问题 ”标签页将 包含 Schemeful Same-Site 问题。您可能会看到系统为您的网站突出显示了以下问题。

导航问题：

• “完全迁移到 HTTPS，以便继续在同网站请求中发送 Cookie” - 警告，Cookie 将 在 Chrome 的未来版本中被屏蔽。
• “完全迁移到 HTTPS，以便在同网站请求中发送 Cookie” - 警告，Cookie 已被 屏蔽。

子资源加载问题：

• “完全迁移到 HTTPS，以便继续将 Cookie 发送到同网站子资源”或“完全迁移到 HTTPS，以便继续允许同网站子资源设置 Cookie” - 警告，Cookie 将 在 Chrome 的未来版本中被屏蔽。
• “完全迁移到 HTTPS，以便将 Cookie 发送到同网站子资源”或“完全迁移到 HTTPS，以便允许同网站子资源设置 Cookie” - 警告，Cookie 已被 屏蔽。在发布表单时，也可能会显示后一种警告。

如需了解更多详情，请参阅 Schemeful Same-Site 的测试和调试提示。

从 Firefox 79 开始，通过 about:config 将 network.cookie.sameSite.schemeful 设置为 true 后，控制台将显示 Schemeful Same-Site 问题的消息。 您可能会在网站上看到以下内容：

• “Cookie cookie_name 即将 被视为针对 http://site.example/ 的跨网站 Cookie，因为架构不匹配。”
• “Cookie cookie_name 已被 视为针对 http://site.example/ 的跨网站 Cookie，因为架构不匹配。”

常见问题解答

我的网站已完全支持 HTTPS，为什么我在浏览器的 DevTools 中看到问题？

可能是您的某些链接和子资源仍然指向不安全的网址。

解决此问题的一种方法是使用 HTTP 严格传输安全 (HSTS) 和 includeSubDomain 指令。借助 HSTS + includeSubDomain，即使您的某个网页意外包含不安全的链接，浏览器也会自动使用安全版本。

如果我无法升级到 HTTPS，该怎么办？

虽然我们强烈建议您将网站完全升级到 HTTPS 以保护用户，但如果您自己无法升级，建议您与托管服务提供商联系，看看他们是否可以提供该选项。如果您是自行托管， 则 Let's Encrypt 提供了许多工具来 安装和配置证书。您还可以考虑将网站移到 CDN 或其他可以提供 HTTPS 连接的代理后面。

如果仍然无法实现，请尝试放宽受影响 Cookie 的 SameSite 保护。

• 如果仅屏蔽了 SameSite=Strict Cookie，您可以将保护级别降低到 Lax。
• 如果 Strict 和 Lax Cookie 都被屏蔽，并且您的 Cookie 被发送到（或从）安全网址设置，您可以将保护级别降低到 None。
  • 如果您要将 Cookie 发送到（或从中设置）的网址不安全，此解决方法将失败 。这是因为 SameSite=None 需要 Cookie 具有 Secure 属性，这意味着这些 Cookie 可能无法通过不安全的连接发送或设置。在这种情况下，您将无法访问该 Cookie，直到您的网站升级到 HTTPS。
  • 请注意，这只是暂时的，因为第三方 Cookie 最终将被完全淘汰。

如果我没有指定 SameSite 属性，这会对我的 Cookie 产生什么影响？

没有 SameSite 属性的 Cookie 会被视为指定了 SameSite=Lax，并且相同的跨架构行为也适用于这些 Cookie。请注意，不安全方法的临时例外情况仍然适用， 如需了解详情，请参阅 Chromium SameSite 常见问题解答 中的 Lax + POST 缓解措施。

WebSocket 会受到什么影响？

如果 WebSocket 连接与网页的安全性相同，则仍会被视为同网站连接。

同网站：

• 来自 https:// 的 wss:// 连接
• 来自 http:// 的 ws:// 连接

跨网站：

• 来自 http:// 的 wss:// 连接
• 来自 https:// 的 ws:// 连接