存储分区

为了加强用户隐私保护并防范边信道跨网站跟踪，Chrome 现在通过一项名为“存储分区”的流程，隔离第三方上下文中的大多数存储和通信 API。

实现状态

我们已为使用 Chrome 115 及更高版本的所有用户启用此功能。其他主要浏览器（如 Firefox 和 Safari）也已实施或计划实施类似的存储分区措施。GitHub 上的存储分区提案已开放供进一步讨论。

什么是存储分区？

为了防止某些类型的边信道跨网站跟踪，Chrome 会在第三方上下文中划分存储空间和通信 API。

如果不进行存储分区，网站可以联接不同网站中的数据，以便在网络上跟踪用户。此外，它还允许嵌入式网站使用边信道技术（例如时间攻击、XS-Leaks 和 COSI）推断顶级网站中用户的特定状态。

过去，存储空间仅按来源设置键值。这意味着，如果 a.com 和 b.com 中嵌入了 example.com 中的 iframe，它可以通过存储 ID 并从存储空间中成功检索该 ID，了解您在这些网站上的浏览习惯。启用第三方存储分区后，example.com 的存储空间会位于两个不同的分区中，一个用于 a.com，另一个用于 b.com。

一般来说，分区意味着由 iframe 中的存储 API（例如 localStorage 和 IndexedDB）写入的数据将无法再被共享相同源的所有上下文访问。相反，这些数据现在是隔离的，并且仅适用于共享相同来源和相同顶级网站的情境。

之前

不进行分区的存储 API。
在存储分区之前，example.com 可以在嵌入到 a.com 时写入数据，然后在嵌入到 b.com 时读取这些数据。

之后

支持分区的存储 API。
存储空间分区后，当 example.com 嵌入到 b.com 中时，无法再访问嵌入到 a.com 中的 example.com 的存储空间。

链接的 iframe 上的存储分区

嵌套 iframe 时，存储分区的复杂性会显著增加，尤其是当链中出现多次相同来源时。

例如，A1 包含 B 的 iframe，B 包含 A2 的 iframe，并且 A1 和 A2 位于同一网站上。如果分区仅考虑顶级网站和当前框架的来源，则 iframe A2 可能会被误认为是“第一方”，因为它与顶级网站 (A1) 共用一个网站，尽管中间有跨网站 iframe B。如果 A2 默认有权访问未分区的存储空间，则可能会导致 A2 面临点击劫持等安全风险。

为解决此问题，Chrome 会向存储分区键添加“祖先位”。如果当前 iframe 和顶级网站之间的任何文档都来自其他（跨网站）来源，系统就会设置此位。在本例中，站点 B 是跨站点，因此系统会为 A2 设置该位，并将其存储空间从 A1 分区。

如果 iframe 链仅由同一网站上下文组成（例如，网站 A1 包含 A2，A2 包含 A3），祖先位不会进一步划分其存储空间。在这种情况下，其存储空间仍会共享，并以其共同的来源和顶级网站作为键。

对于需要跨链接的 iframe 实现未分区访问的网站，Chrome 正在尝试扩展 Storage Access API 以实现此用例。由于 Storage Access API 要求嵌套的网站明确调用该 API，因此这会降低点击欺骗风险。

因分区而发生的 API 更改

受分区影响的 API 可分为以下几类：

Storage API

  • 配额系统
    配额系统用于确定为存储分配了多少磁盘空间。配额系统会将每个分区视为一个单独的分桶，以确定允许的空间大小以及清除空间的时间。
    navigator.storage.estimate() 方法现在提供特定于存储分区的相关信息。仅限 Chrome 的 API（例如 window.webkitStorageInfo 和 navigator.webkitTemporaryStorage）已被弃用。
    IndexedDB 和缓存存储使用分区配额系统。
  • Web Storage API
    Web Storage API 提供了浏览器可以通过的机制来存储键值对。有两种机制：本地存储和会话存储。它们不受配额管理，但仍会进行分区。
  • 源私有文件系统
    File System Access API 允许网站在用户授予访问权限后，直接读取或保存对设备上文件和文件夹的更改。借助源私有文件系统，源可以直接将私密内容存储到磁盘。用户仍可访问此类内容，但现在已分区。
  • Storage Bucket API
    Storage Bucket API 正在为 Storage Standard 开发，该 API 通过使用名为存储分区的新概念，整合了 IndexedDB 和 localStorage 等各种存储 API。存储在存储分区中的数据以及与存储分区关联的元数据会进行分区。
  • Clear-Site-Data 标头
    在响应中添加 Clear-Site-Data 标头后，服务器可以请求清除存储在用户浏览器中的数据。可以清除缓存、Cookie 和 DOM 存储空间。使用该标头只会清除一个分区中的存储空间。
  • Blob 网址存储
    Blob 网址可用于访问blob（一种存储原始数据的对象）。从 Chrome 137（发布时间为 2025 年 5 月 27 日）开始，Blob 网址通常会被分区以进行提取和导航。这意味着，其访问权限现在受存储空间键的范围限制，其中包括顶级网站、帧源以及一个布尔值，用于指示是否存在跨网站祖先。不过，对 Blob 网址的顶级导航仍仅按帧源进行分区。我们正在讨论，对于特定用例（例如顶级导航），Blob 网址存储区最终可能按代理集群（而不仅仅是顶级网站）设置键。Blob 网址分区的这一特定方面仍在不断发展，其确切机制可能会发生变化。

通信 API

除了存储 API 之外，允许一个上下文跨源边界进行通信的通信 API 也会进行分区。这些变更主要影响允许使用广播或同源集合点发现其他上下文的 API。

由于分区，以下通信 API 会阻止第三方 iframe 与其同源上下文交换数据：

  • 广播频道
    Broadcast Channel API 允许浏览上下文（窗口、标签页或 iframe）与同源工作器之间进行通信。
    我们不建议更改跨网站 iframe postMessage() 的行为，因为这些上下文之间的关系已明确定义。
  • SharedWorker
    SharedWorker API 提供了一个可跨同一源的浏览上下文访问的工作器。
  • 网页锁定
    借助 Web Locks API，在同一个源的某个标签页或工作器中运行的代码可以在执行某些工作时为共享资源获取锁。

Service Worker API

借助 Service Worker API，网站可以在后台执行任务。网站会注册服务工件，这些工件会创建新的工件上下文来响应事件。传统上，这些 worker 可以与任何同源上下文进行通信。不过，由于 Service Worker 可以更改导航请求的时间，因此存在跨网站信息泄露（例如历史记录嗅探）的风险。

因此，从第三方环境注册的 Service Worker 现在会进行分区。

扩展程序 API

扩展程序是可让用户自定义浏览体验的程序。

扩展程序页面（采用 chrome-extension:// 架构的网页）可嵌入到网络上的网站中。在这种情况下，扩展程序页面仍可以访问其顶级分区。扩展程序还可以嵌入其他网站；如果这样做，这些嵌入的网站将访问其顶级分区，前提是该扩展程序对这些网站拥有主机权限。

如需了解详情，请参阅扩展程序文档。

演示：测试存储分区

演示网站：https://storage-partitioning-demo-site-a.glitch.me/

演示网站，左侧显示绿色对勾标记，右侧显示红色叉号。
演示的屏幕截图，左侧显示了启用存储分区功能的浏览器的输出，右侧显示了未启用存储分区功能的浏览器的输出。

该演示使用了两个网站：网站 A 和网站 B。

  • 当您在顶级上下文中访问网站 A 时，该网站会使用各种存储方法设置数据。
  • 网站 B 嵌入了网站 A 中的某个网页，并且该嵌入会尝试读取之前设置的存储选项。
  • 当网站 A 嵌入到网站 B 中时，在存储空间分区后，网站 A 将无法访问这些数据，因此读取会失败。
  • 该演示使用每次读取的成功或失败情况来显示数据是否已分区。

目前，您可以使用 --disable-features=ThirdPartyStoragePartitioning 命令行开关在 Chrome 中关闭存储分区。注意：此命令行开关仅用于开发和测试目的，可能会在未来的 Chrome 版本中移除或更改。

您还可以通过相同的方式测试其他浏览器，以查看它们的分区状态。

互动和分享反馈