“same-site”的定义将纳入网址协议,因此网站的 HTTP 和 HTTPS 版本之间的链接现在也会被计为跨网站请求。请默认升级到 HTTPS 以尽可能避免出现问题,也可以继续阅读,详细了解所需的 SameSite 属性值。
有计划性 Same-Site 将(网站)网站的定义从仅可注册域名修改为 方案 + 可注册域名。如需了解更多详情和示例,请参见 了解“same-site”和 "same-origin"。
值得高兴的是,如果您的网站已完全升级为 HTTPS,那么 无需担心什么您不会受到任何影响。
如果您尚未完全升级您的网站,则应优先升级。
不过,在某些情况下,网站访问者会在 HTTP 和
HTTPS,那么一些常见的场景以及相关的 SameSite
Cookie
行为如下所述。
您可以启用这些更改,以便在 Chrome 和 Firefox 中进行测试。
- 在 Chrome 86 中,启用
about://flags/#schemeful-same-site
。跟踪进度 Chrome 状态 页面。 - 在 Firefox 79 中,通过
network.cookie.sameSite.schemeful
true
about:config
。通过错误 问题。
更改为 SameSite=Lax
作为
Cookie 是为了防止跨网站请求伪造
(CSRF)。不过,
不安全的 HTTP 流量仍为网络攻击者提供了
之后会用在安全 HTTPS 版本的
网站。在架构之间创建这种额外的跨网站边界可提供
进一步防御这些攻击。
常见的交叉方案场景
导航
在网站的跨架构版本之间导航(例如,从
从 http://site.example 改为 https://site.example)之前会允许访问
要发送 SameSite=Strict
个 Cookie。现在,此网址被视为“跨网站”
导航,这意味着系统将屏蔽 SameSite=Strict
Cookie。
![在网站的不安全 HTTP 版本上点击指向安全 HTTPS 版本的链接,从而触发跨架构导航。SameSite=Strict Cookie 被屏蔽,SameSite=Lax,并且 SameSite=None;允许使用安全 Cookie。](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-navigation-209071cf80318.png?authuser=6&hl=el)
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 或跨网站 Cookie 需要 Secure
。
![交叉架构子资源,源自网站的安全 HTTPS 版本中的资源,且该子资源包含在不安全的 HTTP 版本中。SameSite=Strict 和 SameSite=Lax Cookie 已被屏蔽,并且 SameSite=None;允许使用安全 Cookie。](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-subresourc-ee291fec730b8.png?authuser=6&hl=el)
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 版本提交网站的不安全 HTTP 版本上的表单产生的跨架构表单提交。SameSite=Strict 和 SameSite=Lax Cookie 已被屏蔽,并且 SameSite=None;允许使用安全 Cookie。](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-form-submi-528e4c1eb4c83.png?authuser=6&hl=el)
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 已经完全被淘汰
- 如果您要将 Cookie 发送到的网址(或者
均是不安全的。这是因为
如果我未指定 SameSite
属性,这对我的 Cookie 有何影响?
没有 SameSite
属性的 Cookie 会被视为已指定
SameSite=Lax
,并且相同的跨架构行为也同样适用于这些 Cookie,
。请注意,不安全方法的临时异常仍然适用,请参阅
Chromium 中的 Lax + POST 缓解措施SameSite
常见问题解答。
WebSocket 会受到什么影响?
如果 WebSocket 连接相同,则仍会被视为同一网站 页面的安全性
同一网站:
- 来自
https://
的wss://
个连接 - 来自
http://
的ws://
个连接
跨网站:
- 来自
http://
的wss://
个连接 - 来自
https://
的ws://
个连接
摄影:Julissa 卡普德维亚语 已开启 不启动