Defaults.Exposed › 修复 › Referrer-Policy（来源页策略）

如何修复 Referrer-Policy（来源页策略）

Referrer-Policy 是你网站交给每位访客浏览器的一条简单指令，控制当访客点击通往别的网站的链接时，你的网址会随他们带走多少。少了它，他们当时所在那个页面的完整网址——搜索词、账号、重置链接、内部页面路径，统统在内——会被悄悄交给他们接着落地的那个网站，包括广告商、分析公司，以及链接指向的任何地方。

对您业务的关键影响： 每当访客点击一个外部链接、广告或共享资源，他们的浏览器都可能把你页面的完整网址交给目标站点——而如果你的网址里带着搜索词、客户 ID、订单号或一次性链接，你就在向自己无法掌控的第三方泄露客户数据。这是监管机构严肃对待的数据保护问题，是一项被悄悄打破的隐私承诺，也是客户安全团队在尽职调查时会标记出来的计分漏洞。

这会让您付出什么代价

• 客户填了表单或做了一次搜索，然后点击一个外部链接或广告——于是连同他们输入的内容在内的页面网址，被直接交给了你从没打算分享给的广告商或分析公司。
• 密码重置和账户确认链接有时会在网址里带着一个秘密令牌；没有这条响应头，点击该页面上的任何链接都可能把整个网址——连令牌一起——传给外部站点。
• 私密的内部页面路径（管理后台、仅限客户的页面、定价分层、文档链接）会被暴露给访客点过去的每一个第三方，等于把你网站的地图交给本不该看到它的竞争对手和窥探者。
• 客户的安全审查或隐私审计扫描你的网站，发现没有 Referrer-Policy，便把它记为数据最小化失职——这类发现足以拖住一份合同或一项认证。
• 个人数据落入你与之没有任何协议的数据处理方手中，把一次五分钟的疏忽变成一起须上报的数据保护事故。

为什么它重要。 浏览器若任其自便，是很爱多嘴的：它们默认会告诉下一个网站访客刚从哪里来，往往连页面的完整网址一起带上。对一个纯展示型网站这也许无害，但只要你的网址里含有任何私密信息——一个搜索词、一个订单 ID、一个链接里的邮箱、一条私密路径——这个默认行为就会悄悄把它泄露给外部方。Referrer-Policy 正是那一个让浏览器停止过度分享的设置。它是评分卡上一项实打实得分的计分检查，直接对应隐私法下的数据最小化义务，也是任何专业审查都期望看到的标准安全响应头之一。

一句话说清这是什么

每当你网站上的访客点击通往另一个站点的链接——一个外部链接、一条横幅广告、一个分享此页、甚至一个从别处加载的字体或图片——他们的浏览器都会悄悄附上一张便条，说明他们从你的哪个页面过来。这张便条就叫来源页（referrer）。

用得合理，来源页无害甚至有用：别的网站正是靠它知道流量来自你，许多正当的分析也靠它支撑。问题出在默认行为上。若不加管理，浏览器不只是说他们来自 your-business.com——它往往会交出那个确切页面的完整网址，包括域名之后的一切。而网址承载的远比人们以为的多：输入到你网站里的搜索词、订单号和账号、通往一个仅限会员页面的路径，甚至密码重置和确认链接里的一次性秘密令牌。

Referrer-Policy 是你网站发给浏览器的一条指令，规定它可以分享那张便条里的多少内容。你可以让它只分享你的域名、只分享给你自己网站上的其他页面，或者什么都不分享。把它想成这样的差别：要么把写满日程的完整家庭住址递给一个陌生人，要么只告诉对方你住在哪个城市。

它属于一小族安全响应头——你网站给每位访客浏览器的简短指令。它不改变你网站的外观或运作。它只是让浏览器别替你过度分享。

这会让你付出什么代价

下面是缺失或宽松的 Referrer-Policy 咬伤真实企业的几种具体、日常的方式。它们都不需要黑客——它们在正常使用中每天自动发生。

• **被泄露的搜索。**客户在你网站上搜索某种敏感的东西——一款医疗产品、一项与债务相关的服务、一份竞品对比——而搜索词落进了页面网址里。接着他们点击该结果页上的一个外部链接或广告。广告商现在收到了你的网址连同其中的搜索词，从而准确得知你的客户在找什么。你从未同意分享它，而且收不回来。

• **暴露的重置链接。**许多系统会把一次性秘密令牌放进密码重置、邮箱确认或一键登录页面的网址里。如果那个页面包含任何外部链接或第三方资源，完整网址——连令牌一起——就可能被交给外部站点。最糟的情况下，这等于把一个账户的钥匙递给了第三方。

• **你免费送出的网站地图。**你的内部页面路径往往会暴露你的结构：/admin、/enterprise-pricing、/clients/acme、/downloads/private-report。没有这条响应头，访客点过去的每一个外部站点都会收到这些路径。竞争对手摸清你的定价分层和产品线；爬虫摸清该盯哪些页面。

• **不情愿的数据共享关系。**隐私法要求你知道客户的个人数据流向了谁，并要有协议在先。把含有客户 ID 或邮箱地址的页面网址，在没有协议、没有同意的情况下泄露给广告网络和分析公司——这正是那种会把一次例行审计变成发现项、再把发现项变成须上报事故的失控数据流。

• **卡在尽职调查上的交易。**当一个较大客户的安全团队审查你时，缺失标准安全响应头是一个快速、自动的勾选项。看到 Referrer-Policy 缺失，会告诉他们基础隐私卫生从未做过——而这个印象会给整场审查的其余部分都染上色彩。

它实际上是什么

默认情况下，现代版本的浏览器遵循一种大致等同于 strict-origin-when-cross-origin 的行为——但你不能依赖它，因为旧浏览器、内嵌网页视图和某些配置仍会退回到泄露更多。唯一保险的办法是显式设置该策略。设置时，你是在一份简短清单中选一条规则。要紧的有：

• no-referrer——什么都不分享。下一个站点对访客从哪里来一无所知。隐私最大化；可能削弱你的引荐分析。
• same-origin——仅当访客在你自己网站的页面之间移动时分享完整网址；对外部站点什么都不分享。
• strict-origin-when-cross-origin——推荐的默认值。在你自己网站内部，分享完整路径；对外部站点，只分享你光秃秃的域名（从安全页面前往不安全页面时则完全不分享）。外部方知道流量来自你，却永远不知道你域名之后的私密细节。
• origin——始终只分享你的域名，即便在你自己网站内部也是如此。

以及两个要避免的取值，因为评分卡把它们视同根本没有响应头：

• unsafe-url——永远向所有人分享完整网址。一个词概括的最坏情况。
• no-referrer-when-downgrade——旧的浏览器默认值；它仍会把完整网址发给其他安全站点，泄露上面描述的一切。

**良好的状态长什么样：**存在一条 Referrer-Policy 响应头，且设为收紧的取值——对大多数企业是 strict-origin-when-cross-origin。这既让引荐分析照常工作，又确保你域名之后的任何内容永远不会到达外部站点。

如何修复（免费，约 5 分钟）

**把这一节交给你的 IT 人员、网页开发人员或主机服务商——修复是免费的，只有一行，而且不会弄坏你的网站。**这里没有什么有风险的上线：不像某些安全设置，一个合理的 Referrer-Policy 不会让你的链接或页面停止工作。它只是裁剪分享给别的网站的内容。

目标：设置一条值为 strict-origin-when-cross-origin 的 Referrer-Policy 响应头（如果你想分享得更少，也可设更严的值）。

Cloudflare（无需代码——如果你用它，这是最简单的）： 仪表盘 → 你的域名 → Rules → Transform Rules → Modify Response Header → Create rule → Set static → 响应头名 Referrer-Policy，值 strict-origin-when-cross-origin → 应用于所有进入的请求 → Deploy。

**Google Workspace / Microsoft 365：**这些管理的是你的邮箱，不是你的网站，所以响应头要设在你网站实际托管的地方（你的 Web 主机、CDN 或服务器）——而不是 Workspace 或 365 的管理后台。先确定主机，再用下面对应的方法。

Nginx：

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Apache（在站点配置或 .htaccess 中）：

Header always set Referrer-Policy "strict-origin-when-cross-origin"

IIS（web.config）：

<httpProtocol><customHeaders>
  <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
</customHeaders></httpProtocol>

Node / Express：

app.use((req, res, next) => { res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin'); next(); });

**WordPress / 常见主机：**大多数托管型 WordPress 和共享主机都允许你通过安全插件、主机控制面板里的响应头面板，或上面的 .htaccess 片段来加响应头。如果你在 Cloudflare 后面，Cloudflare 的方法最干净，一次就全站生效。

**应用之后：**打开你的网站并重新运行检查，或用浏览器的开发者工具（网络标签页 → 点击主文档 → 响应头）确认 Referrer-Policy: strict-origin-when-cross-origin 存在。

常见错误

• 设了个宽松值，却以为它算数。unsafe-url 和 no-referrer-when-downgrade 仍然都会泄露完整网址。评分卡给它们记零——和没有响应头完全一样。如果响应头在、分数却不在，几乎总是这个原因。
• **只在首页设置它。**这条响应头应该在每个页面上发送，因为泄露发生在搜索结果页、账户页和重置页上——而不是首页。在服务器、CDN 或 Cloudflare 层面设置，让它自动全站生效。
• 只在 HTML 的 <meta> 标签里设置它。<meta name="referrer"> 标签对某些情况有效、但不是全部，而且很容易在各页面之间出现不一致。把它设成一条正经的响应头（上面的方法）才是可靠的做法。
• **让一层覆盖另一层。**如果你的源站服务器和 CDN 都设了这条响应头、却取值不同，结果可能难以预料。挑一个地方来统管它——如果你有 CDN 或 Cloudflare，通常选它们——并让其余保持一致。
• **把它当成把数据排除在网址之外的替代品。**响应头限制了损害，但更干净的长期习惯，是一开始就不要把秘密和个人数据放进网址。现在先用响应头；把网址卫生作为后续工作提给你的开发人员。

关于相关响应头的简短说明

Referrer-Policy 与我们检查的另外几个网页安全响应头并列——Content-Security-Policy、X-Frame-Options、X-Content-Type-Options，以及几个高级的跨源响应头。它们防护的是不同的东西，所以有其一并不覆盖其余。如果你的 Referrer-Policy 缺失，值得请修它的人同时确认其他标准响应头也已到位，因为它们通常配置在同一个地方，顺手做完不另外花成本。

简而言之

Referrer-Policy 是你评分卡上最便宜、最安全的隐私修复：一行，约五分钟，没有弄坏任何东西的风险，而且免费。它阻止访客的浏览器把你私密的页面网址——以及其中所含的任何个人数据——悄悄交给他们点过去的每一个外部站点。把它设成 strict-origin-when-cross-origin，确认它在每个页面上都已生效，那个中等严重级的漏洞及其 15 分就堵上了。

常见问题