Schemeful Same-Site

“same-site”的定义将纳入网址协议，因此网站的 HTTP 和 HTTPS 版本之间的链接现在也会被计为跨网站请求。请默认升级到 HTTPS 以尽可能避免出现问题，也可以继续阅读，详细了解所需的 SameSite 属性值。

Steven Bingler

Rowan Merewood

注意 ：本文是关于 SameSite Cookie 属性变更的系列文章中的一篇，这些变更包括：

• 了解 Cookie
• SameSite Cookie 说明
• SameSite Cookie 的诀窍

有计划性 Same-Site 将（网站）网站的定义从仅可注册域名修改为 方案 + 可注册域名。如需了解更多详情和示例，请参见 了解“same-site”和 "same-origin"。

关键术语 ：这意味着，对于同一个网站的不安全 HTTP 版本（例如 http://website.example）和该网站的安全 HTTPS 版本 https://website.example，现在彼此之间会被视为跨网站。

值得高兴的是，如果您的网站已完全升级为 HTTPS，那么 无需担心什么您不会受到任何影响。

如果您尚未完全升级您的网站，则应优先升级。 不过，在某些情况下，网站访问者会在 HTTP 和 HTTPS，那么一些常见的场景以及相关的 SameSite Cookie 行为如下所述。

警告 ：我们的长期计划是逐步完全支持第三方 Cookie，用可保护隐私的替代方案取而代之。在向完整 HTTPS 迁移的过程中，只应考虑在 Cookie 上设置 SameSite=None; Secure 以允许其跨架构发送。

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

• 在 Chrome 86 中，启用 about://flags/#schemeful-same-site。跟踪进度 Chrome 状态 页面。
• 在 Firefox 79 中，通过network.cookie.sameSite.schemefultrue about:config。通过错误 问题。

更改为 SameSite=Lax 作为 Cookie 是为了防止跨网站请求伪造 (CSRF)。不过， 不安全的 HTTP 流量仍为网络攻击者提供了 之后会用在安全 HTTPS 版本的 网站。在架构之间创建这种额外的跨网站边界可提供 进一步防御这些攻击。

常见的交叉方案场景

关键术语 ：在下面的示例中，所有网址都具有相同的可注册域名，例如site.example 不同的架构，但 httphttp://site.example 与 https://site.example 不同，它们彼此称作交叉架构<br class="ph-1.

导航

在网站的跨架构版本之间导航（例如，从 从 http://site.example 改为 https://site.example）之前会允许访问 要发送 SameSite=Strict 个 Cookie。现在，此网址被视为“跨网站” 导航，这意味着系统将屏蔽 SameSite=Strict Cookie。

从 HTTP 到 HTTPS 的交叉架构导航。

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ 已屏蔽	⛔ 已屏蔽
SameSite=Lax	✓ 允许	✓ 允许
SameSite=None;Secure	✓ 允许	⛔ 已屏蔽

正在加载子资源

警告 ：所有主流浏览器都会屏蔽混合主动内容，例如脚本或 iframe。此外，包括 Chrome 和 Firefox 在内的浏览器正在着手升级或屏蔽被动混合内容。

您在此处所做的任何更改只会被视为临时修复， 努力升级到完整的 HTTPS

子资源的示例包括图片、iframe 和使用 XHR 或 Fetch。

以前，在网页上加载交叉架构子资源 要发送或设置的 SameSite=Strict 或 SameSite=Lax Cookie。现在 对第三方资源或跨网站子资源的处理方式 意味着任何 SameSite=Strict 或 SameSite=Lax Cookie 都会被屏蔽。

此外，即使浏览器允许来自不安全方案的资源 在安全网页上加载，则对于此类请求，系统将阻止所有 Cookie， 第三方 Cookie 或跨网站 Cookie 需要 Secure。

包含通过 HTTPS 的交叉架构子资源的 HTTP 网页。

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ 已屏蔽	⛔ 已屏蔽
SameSite=Lax	⛔ 已屏蔽	⛔ 已屏蔽
SameSite=None;Secure	✓ 允许	⛔ 已屏蔽

发布表单

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

与子资源一样，如果请求来自HTTPS 转换成 不安全，例如HTTP、上下文，则在这些请求中，所有 Cookie 都会被屏蔽 因为第三方或跨网站 Cookie 需要 Secure。

警告 ：此处的最佳解决方案是确保表单页面和目标页面均采用安全连接，例如 HTTPS。如果用户在表单中输入任何敏感信息，这一点尤为重要。

。 <ph type="x-smartling-placeholder">

</ph>

从 HTTP 到 HTTPS 的跨架构表单提交。

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ 已屏蔽	⛔ 已屏蔽
SameSite=Lax	⛔ 已屏蔽	⛔ 已屏蔽
SameSite=None;Secure	✓ 允许	⛔ 已屏蔽

如何测试我的网站？

Chrome 和 Firefox 支持开发者工具和消息功能。

在 Chrome 86 中，“问题”标签页 开发者工具会 包括 Schemeful Same-Site 问题。您可能会看到以下问题突出显示 。

导航问题：

• "完全迁移至 HTTPS，继续在同一网站上发送 Cookie 请求”- 一条警告，指出未来版本中将屏蔽 Cookie 。
• “完全迁移到 HTTPS，使 Cookie 能够针对同网站请求发送”- A 显示 Cookie 已被屏蔽的警告。

子资源加载问题：

• "完全迁移至 HTTPS，继续将 Cookie 发送到同一网站 子资源”或“完全迁移到 HTTPS 以继续允许 Cookie 由 same-site 子资源设置”- 警告用户如果将 会在以后的 Chrome 版本中遭到阻止。
• "完全迁移到 HTTPS，将 Cookie 发送到同网站子资源" 或“完全迁移到 HTTPS，以允许 Same-site 设置 Cookie 子资源”- 提醒您 Cookie 已被屏蔽的警告。后者 发布表单时也会显示警告。

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

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

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

常见问题解答

我的网站已经完全支持 HTTPS，为什么我在浏览器的开发者工具中看到问题？

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

解决此问题的一种方法是使用 HTTP 严格传输安全 (HSTS) 和 includeSubDomain 指令。HSTS + includeSubDomain 均匀 如果您的某个网页意外包含不安全的链接，那么浏览器将会 并自动改用安全版本

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

尽管我们强烈建议您将网站完全升级到 保护您的用户，如果您自己无法做到这一点，我们建议您与 与托管服务提供商联系，看看他们能否提供该选项。如果您是自助托管者， Let's Encrypt 提供了许多工具 安装并配置证书您还可考虑将您的网站 位于 CDN 或其他可提供 HTTPS 连接的代理之后。

如果仍无法实现，请尝试放宽SameSite Cookie。

• 如果只屏蔽了 SameSite=Strict 个 Cookie，您可以降低 将保护措施设置为 Lax。
• 如果 Strict 和 Lax Cookie 都被阻止，而您的 Cookie 被发送到（或是从）安全网址设置，您可以降低 None。
  • 如果您要将 Cookie 发送到的网址（或者 均是不安全的。这是因为 SameSite=None 要求 Secure 属性，则意味着这些 Cookie 不会被发送或 通过不安全的连接进行设置。在这种情况下，您将无法访问 该 Cookie，直到您的网站升级到 HTTPS。
  • 请注意，这种情况只是暂时的，因为最终第三方 Cookie 已经完全被淘汰

如果我未指定 SameSite 属性，这对我的 Cookie 有何影响？

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

WebSocket 会受到什么影响？

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

同一网站：

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

跨网站：

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

摄影：Julissa 卡普德维亚语 已开启 不启动