从 Chrome 135 开始,您可以使用新的 sandbox
值:allow-same-site-none-cookies
。指定此政策且第三方 Cookie 不可用时,浏览器将仅在来自第一方沙盒化 iframe 的 HTTP 请求中发送 SameSite=None
Cookie。
什么是沙盒化 iframe?
沙盒化 iframe 是指受特殊限制的 iframe。系统会将其视为具有 null
不透明来源。默认情况下,沙盒化 iframe 中不支持脚本、表单和弹出式窗口等潜在有害功能。
使用 sandbox
属性指定沙盒化 iframe 应具有哪些功能。例如:
<iframe sandbox="allow-scripts" src="example-sandboxed-frame.html"/>
沙盒化始终是一个好主意,因为它可让您精细选择嵌入内容成功加载所需的权限,同时限制潜在漏洞的范围。
为什么需要这项新政策?
在引入 allow-same-site-none-cookies
之前,您可以在沙盒化 iframe 中配置两种 Cookie 场景:
- 如果
sandbox
属性中没有allow-same-origin
令牌,则 iframe 的来源会序列化为null
,使沙盒化网页中的所有请求都成为跨网站请求。在这种情况下,请求中将仅包含包含SameSite=None
的 Cookie。 - 在
sandbox
属性中使用allow-same-origin
令牌后,系统会将请求视为来自 iframe 的真实来源,从而允许发送具有任何SameSite
值的 Cookie。
在第三方 Cookie 被屏蔽的情况下,缺少 allow-same-origin
的沙盒化 iframe 无法发送任何 Cookie,除非您启用 allow-same-site-none-cookies
。
即使第三方 Cookie 被屏蔽,包含 allow-same-origin
的 iFrame 仍可在同一网站请求中包含 Cookie。不过,整个源的 Cookie Jar 将会暴露于潜在的恶意 Web 活动。
使用 allow-same-site-none-cookies
时,iframe 可以在 HTTP 请求中发送 SameSite=None
Cookie,而不会包含可能敏感的 SameSite=Strict
和 SameSite=Lax
Cookie。
实际示例
假设有一个网站 practice-coding.example
,允许用户创建和运行自定义编码项目,以及嵌入其他用户的代码。用户必须登录才能使用该服务,这会导致系统设置 SameSite=Strict
会话 Cookie。
另一位用户创建了一个项目 practice-coding.example/cookie-theft
,其他用户可能会在不知情的情况下将其作为 iframe 嵌入到自己的项目中。如果 SameSite=Strict
和 SameSite=Lax
Cookie 会泄露给 practice-coding.example/cookie-theft
iframe,恶意用户可能会盗取其他用户的会话 Cookie。
在这种情况下,网站所有者可能需要限制对可能敏感的 Cookie 的访问权限。不过,他们可能仍希望在沙盒化 iframe 中允许 SameSite=None
Cookie。例如,practice-coding.example/coding-interview
沙盒化 iframe 可能需要 SameSite=None
Cookie 才能允许候选者重新访问其代码。allow-same-site-none-cookies
可防止公开整个 Cookie Jar,同时有选择地允许必要的 SameSite=None
Cookie。
如何仅在第一方沙盒化框架中允许 SameSite=None
?
如需在来自第一方沙盒化网页的请求中启用 SameSite=None
Cookie,请在 iframe 代码中指定 allow-same-site-none-cookies
令牌。例如:
<iframe sandbox="allow-same-site-none-cookies" src="example-sandboxed-page.html"/>
您还可以使用 Content-Security-Policy
HTTP 标头设置 allow-same-site-none-cookies
政策:
Content-Security-Policy: sandbox allow-same-site-none-cookies;
您可以通过我们的演示版自行试用。