从 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 都会暴露给潜在的恶意网络活动。
借助 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;
不妨通过我们的演示自行尝试一下。
互动和分享反馈
提交问题以分享反馈或报告问题，或者加入 GitHub 上的讨论。