HTTP 层的默认隐私：缩小追踪面的响应头

大多数隐私工作都发生在 JavaScript 中——同意逻辑、标签门控、标识符轮换。但浏览器交给你两个 HTTP 响应头，它们能在任何脚本运行之前就关闭监控面，而大多数网站两者都没有发送。Permissions-Policy 和 Referrer-Policy 是最字面意义上的隐私设计：是配置，不是代码。

它们现在比一年前更加重要。随着 Google 在 2025 年 10 月退役大部分 Privacy Sandbox API，这些 API 引入的残留广告技术指令仍然连接在 Chrome 中——而现在网站可以主动将它们关闭，而不必等待它们被移除。

Permissions-Policy：拒绝你从不使用的特性

Permissions-Policy 控制文档及其嵌入框架可以使用哪些浏览器特性。它与门控 camera、geolocation 和 microphone 的机制相同——但它同样门控了广告技术所依赖的、与追踪相关的 API。

这些 API 的默认允许列表大多很宽松。browsing-topics,即控制 Topics API 的指令,默认为 *——页面上的每个源,包括第三方框架,除非你另行声明,否则都可以调用它。禁用它只需一行：

Permissions-Policy: browsing-topics=()

空的允许列表 () 会对所有人拒绝该特性,包括你自己的源。你可以在单个响应头中锁定整组广告兴趣和测量 API：

Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=(), private-aggregation=()

任何脚本——无论是第一方还是嵌入的——一旦调用 document.browsingTopics() 或发送 Sec-Browsing-Topics 请求头,现在都会以 NotAllowedError 失败。你不是在信任第三方会规矩行事；你是在平台层面移除了这项能力。

这些指令随 Privacy Sandbox 一同被弃用,因此其中一些会在 Chrome 未来的版本中消失。将它们设为 () 在它们消失后无害,而在此之前则起到保护作用。

Referrer-Policy：停止泄露你的 URL

每一次导航和子资源请求都可能携带一个 Referer 头,指明用户来自哪个页面。完整的 URL 会把查询字符串、路径中编码的标识符、搜索词以及内部页面结构泄露给你加载的每一个第三方——分析厂商、字体、CDN、广告像素。

现代浏览器默认采用 strict-origin-when-cross-origin,这已经是一个合理的底线：

Referrer-Policy: strict-origin-when-cross-origin

在此策略下,浏览器仅在 同源 请求时发送完整 URL,在跨源的安全请求时 仅发送源,在从 HTTPS 降级到 HTTP 时 什么都不发送。因此 https://app.example/orders/4815?token=abc 到达第三方时变成 https://app.example/——只有源,没有路径,没有查询字符串。

该默认值于 2020 年 11 月成为规范默认值,但你仍应显式设置该响应头。一个配置错误的上游、一个陈旧的框架默认值,或一个 <meta> referrer 标签都可能覆盖它,而显式的响应头是可审计的。如果你不在 URL 中嵌入任何敏感信息并希望更严格,strict-origin 也会在同源请求中丢弃路径。

为什么它与无 Cookie 分析相辅相成

这些响应头和隐私优先的追踪器从两个方向解决同一个问题。追踪器控制 你的 分析收集什么；响应头控制页面上 其他所有人 能够触及什么。

一个从单向每日哈希——SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD)——派生身份的无 Cookie 追踪器,永远不需要完整的 referrer URL 或 Topics API 来完成它的工作。它读取 document.referrer 仅仅是为了归因访问来源,而源就足以做到这一点。因此收紧 Referrer-Policy 不会给你的分析带来任何成本,同时却为页面上的每一个其他请求堵住了一个泄露口。

同样的契合也体现在性能上。响应头消耗零字节的 JavaScript 和零主线程时间；它们在解析之前由浏览器评估。你获得了可衡量的隐私改进,而对 Largest Contentful Paint 或 Interaction to Next Paint 没有任何影响——这与同意管理平台恰恰相反,后者增加了脚本负担,去管理本可以由一个响应头直接拒绝的权限。

在边缘部署它们

在你的边缘或源服务器设置这两个响应头,使每一个响应都携带它们,包括静态资源和 HTML：

Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=()
Referrer-Policy: strict-origin-when-cross-origin

在 Cloudflare 上,在 Transform Rule 或 Worker 中添加它们；在 Next.js 中,使用 headers() 配置；在任何反向代理中,一行 add_header 即可。这没有发布风险：你拒绝的是你不使用的能力,削减的是你从不想发送的数据。

隐私设计通常被框定为一项架构决策。在 HTTP 层,它就是两行配置,而它们在你关闭之前都默认开放。

来源

• Permissions-Policy 响应头（MDN Web Docs）
• Permissions-Policy：browsing-topics 指令（MDN Web Docs）
• Referrer-Policy 响应头（MDN Web Docs）
• 使用 Permissions Policy 控制浏览器特性（Chrome for Developers）
• Privacy Sandbox 技术计划更新（Google）