“同网站”的定义在不断发展,纳入了网址协议,因此网站的 HTTP 和 HTTPS 版本之间的链接现在会被计为跨网站请求。默认升级到 HTTPS,尽可能避免出现问题;您也可以继续阅读,详细了解需要哪些 SameSite 属性值。
Schemeful Same-Site 只会将(网站)网站的定义从可注册网域修改为 scheme + 可注册网域。如需了解更多详情和示例,请参阅了解“同网站”和“同源”。
好消息是:如果您的网站已经完全升级到 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 问题跟踪进度。
将 SameSite=Lax
更改为 Cookie 的默认设置的一个主要原因是,可以防范跨站请求伪造 (CSRF)。但是,不安全的 HTTP 流量仍可能会让网络攻击者有机会篡改 Cookie,之后 Cookie 便会在安全的 HTTPS 版本上使用。在方案之间创建这种额外的跨网站边界,可以进一步防御这些攻击。
常见的跨架构场景
导航
在网站的跨架构版本之间导航(例如,从 http://site.example 链接到 https://site.example)以前允许发送 SameSite=Strict
Cookie。现在,系统会将此操作视为跨网站导航,这意味着系统会阻止 SameSite=Strict
Cookie。
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ 已屏蔽 | ⛔ 已屏蔽 |
SameSite=Lax
|
✓ 允许 | ✓ 允许 |
SameSite=None;Secure
|
✓ 允许 | ⛔ 已屏蔽 |
正在加载子资源
在您努力升级到完整 HTTPS 时,您在此处所做的任何更改都只应视为临时修复。
子资源的示例包括图片、iframe 以及使用 XHR 或 Fetch 发出的网络请求。
在页面上加载跨架构子资源之前,系统会允许发送或设置 SameSite=Strict
或 SameSite=Lax
Cookie。现在,此资源的处理方式与任何其他第三方或跨网站子资源相同,也就是说,任何 SameSite=Strict
或 SameSite=Lax
Cookie 都会被阻止。
此外,即使浏览器允许将来自不安全方案的资源加载到安全网页上,系统仍会阻止所有 Cookie 在这些请求中被阻止,因为第三方或跨网站 Cookie 需要 Secure
。
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
。
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ 已屏蔽 | ⛔ 已屏蔽 |
SameSite=Lax
|
⛔ 已屏蔽 | ⛔ 已屏蔽 |
SameSite=None;Secure
|
✓ 允许 | ⛔ 已屏蔽 |
如何测试我的网站?
Chrome 和 Firefox 支持开发者工具和消息功能。
从 Chrome 86 开始,开发者工具中的“问题”标签页将包含 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/
的跨网站,因为架构不匹配。”
常见问题解答
我的网站已经完全支持 HTTPS,为什么我在浏览器的开发者工具中看到相关问题?
您的某些链接和子资源可能仍会指向不安全的网址。
解决此问题的一种方法是使用 HTTP Strict-Transport-Security (HSTS) 和 includeSubDomain
指令。使用 HSTS + includeSubDomain
时,即使您的某个页面意外包含不安全的链接,浏览器也会自动改用安全版本。
如果我无法升级到 HTTPS,该怎么办?
虽然我们强烈建议您将网站完全升级到 HTTPS 以保护您的用户,但如果您自己无法做到这一点,我们建议您与托管服务提供商联系,看看他们是否可以提供相应选项。如果您是自行托管,则可以借助 Let's Encrypt 提供的多种工具来安装和配置证书。您还可以考虑将网站移至能够提供 HTTPS 连接的 CDN 或其他代理后面。
如果仍无法实现,请尝试放宽对受影响 Cookie 的 SameSite
保护。
- 如果仅屏蔽
SameSite=Strict
Cookie,您可以将保护级别降低至Lax
。 - 如果
Strict
和Lax
Cookie 均被拦截,且您的 Cookie 被发送到(或从安全网址设置)到安全网址,您可以将保护级别降低至None
。- 如果您要将 Cookie 发送到(或设置 Cookie 的来源)网址不安全,这种做法将失败。这是因为
SameSite=None
需要 Cookie 上的Secure
属性,这意味着,这些 Cookie 可能无法通过不安全的连接发送或设置。在这种情况下,在您的网站升级到 HTTPS 之前,您将无法访问该 Cookie。 - 请注意,这只是暂时的,因为我们最终会完全淘汰第三方 Cookie。
- 如果您要将 Cookie 发送到(或设置 Cookie 的来源)网址不安全,这种做法将失败。这是因为
如果我没有指定 SameSite
属性,这会对我的 Cookie 有何影响?
没有 SameSite
属性的 Cookie 会被视为指定了 SameSite=Lax
,并且相同的跨架构行为也适用于这些 Cookie。请注意,不安全方法的临时例外仍然适用。如需了解详情,请参阅 Chromium SameSite
常见问题解答中的“宽松 + POST 缓解”方法。
WebSocket 会受到什么影响?
如果 WebSocket 连接与页面具有相同的安全性,则仍被视为同站点连接。
同一网站:
- 来自
https://
的wss://
连接 - 来自
http://
的ws://
连接
跨网站:
- 来自
http://
的wss://
连接 - 来自
https://
的ws://
连接
照片由 Julissa Capdevilla 拍摄,拍摄于 Unsplash 网站