网站安全之Referrer Policy与来源信息泄露防范

Referrer Policy 本质上是浏览器的一个安全机制，它控制着当用户从一个页面跳转到另一个页面，或者页面加载图片、脚本、样式等子资源时，是否在 HTTP 请求头中携带 Referer 字段，以及携带多少信息。这个字段一旦处理不当，就会直接把你的网站内部路径、参数甚至用户敏感数据暴露给第三方。

很多网站管理员只关注 SQL 注入、XSS 这类显性漏洞，却忽略了 Referer 信息泄露这个隐蔽通道。举个例子，当你的后台管理页面引用了外部 CDN 的图标库，或者文章页面包含指向其他域名的链接，用户的浏览器就会在请求中自动附上当前页面的完整 URL。如果 URL 里恰好拼接了会话令牌、用户 ID、操作类型等参数，这些信息就相当于拱手送人。

更麻烦的是，市面上绝大多数分析统计工具、广告联盟、社会化分享组件都依赖第三方脚本。这些脚本部署在别人的服务器上，它们能完整接收到 Referer 字段。一旦某个第三方服务商的数据日志发生泄露，或者被恶意内部人员利用，从 Referer 中提取的敏感路径信息就能拼凑出你的网站结构、后台地址，甚至直接拿到带有有效 Token 的操作链接。

要解决这个问题，首先得搞清楚 Referer 在什么场景下会被发送。浏览器的默认行为是：从 HTTPS 页面跳转到 HTTP 页面时不发送 Referer；同源请求默认发送完整 Referer；跨域请求在老旧浏览器上默认发送完整 Referer，而现代浏览器逐渐收紧，但依然存在泄露风险。这种不可预测性恰恰是风险所在，所以不能依赖浏览器默认行为，必须显式声明 Referrer Policy。

Referrer Policy 通过 HTTP 响应头或者 HTML 标签属性来设置，可选值有八个，但真正在安全实践中高频使用的就几个。no-referrer 是最严格的一种，表示任何请求都不发送 Referer 字段，直接把信息泄露通道彻底关闭。这个策略适合对隐私要求极高的场景，比如网银系统、医疗健康平台、企业内部后台。代价是某些需要校验 Referer 来防盗链的资源可能会失效，不过这个问题可以通过其他方式弥补，比如使用 CSRF Token 或自定义请求头验证。

same-origin 策略只对同源请求发送完整 Referer，跨域请求一律不发送。这是平衡安全与功能的最佳选择，绝大多数内容型网站都应该采用这个设置。同源页面之间保留 Referer 可以满足站内统计分析、日志审计的需求，而跨域场景下屏蔽 Referer 则能有效防止信息外泄。比如你的博客文章引用了图床的图片，用户访问时浏览器不会把文章 URL 告诉图床服务器。

strict-origin-when-cross-origin 是目前主流浏览器的默认策略，也是 W3C 推荐的标准。它的行为逻辑是：同源请求发送完整 Referer；跨域请求且协议降级时不发送 Referer；跨域请求且协议不变时只发送源信息，也就是协议加域名加端口，不包含路径和查询参数。这个策略在保护隐私的同时，保留了跨域请求的来源标识能力，第三方服务商只能知道流量来自哪个网站，无法获取具体页面路径。

实际部署时，最简单的做法是在 Web 服务器的配置文件中统一添加响应头。Nginx 下只需在 server 块或 location 块中加入一行 add_header Referrer-Policy "strict-origin-when-cross-origin"; 就能全局生效。Apache 则通过 Header set Referrer-Policy "same-origin" 来实现。如果使用云服务商提供的 CDN 或边缘计算平台，通常都有可视化界面可以直接配置 HTTP 响应头，不需要改动源站代码。

除了服务器全局设置，Referrer Policy 还支持在 HTML 元素级别进行细粒度控制。在 <meta> 标签中可以设置整个页面的策略，比如 <meta name="referrer" content="no-referrer">。这种方式适合无法修改服务器配置的情况，比如托管在第三方平台上的静态网站，或者某个特定页面需要区别于全局策略。

更灵活的是在 a 标签、img 标签、iframe 标签上使用 referrerpolicy 属性。假设你的页面上有一个指向外部合作伙伴的链接，你希望对方知道流量来源是你们网站，但不想暴露具体页面路径，就可以写成 <a href="https://partner-site.com" referrerpolicy="origin">合作伙伴</a>。如果某个图片资源来自不可信的第三方域名，可以设置 <img src="https://third-party.com/image.jpg" referrerpolicy="no-referrer"> 来彻底屏蔽 Referer。

这种元素级别的控制特别适合混合场景。比如网站主体采用 strict-origin-when-cross-origin 策略，但某个页面内嵌了需要 Referer 校验的第三方支付接口，就可以单独给这个接口的 form 标签或 a 标签设置 referrerpolicy="origin-when-cross-origin"，在不影响整体安全的前提下保证业务功能正常运行。

即使设置了合理的 Referrer Policy，也不能完全消除信息泄露风险，因为 Referer 只是泄露渠道之一。真正需要警惕的是 URL 中携带敏感信息的做法本身。很多老旧系统习惯把用户 ID、操作类型、返回地址直接拼接在 URL 查询参数里，比如 /admin/user_edit?id=123&token=abc123&return=/dashboard。这种设计在浏览器地址栏、历史记录、服务器日志、Referer 字段中都会留下痕迹。

解决这个问题需要从架构层面入手。所有涉及用户身份、权限、临时凭证的信息都应该放在 HTTP 请求体中传输，而不是 URL 参数。对于必须通过链接传递的临时 Token，应该使用一次性的、短时效的随机字符串，并且绑定到当前会话，用完后立即失效。页面之间的跳转参数可以通过 SessionStorage 或服务端会话维护，前端路由采用 History API 的 pushState 替换掉带敏感参数的 URL。

还有一个容易被忽视的点是第三方登录回调、OAuth 授权流程中的 state 参数和 code 参数。这些参数虽然设计上是一次性的，但如果回调页面加载了第三方资源，Referer 就会把带有这些参数的完整 URL 发送出去。正确的做法是回调处理页面不加载任何第三方资源，处理完授权后立即重定向到一个干净的页面，利用 302 跳转把敏感参数从 URL 中剥离。

不少开发者依赖 Referer 字段来做防盗链或 CSRF 防御，但 Referrer Policy 的普及让这种做法越来越不可靠。当用户浏览器采用 no-referrer 或 same-origin 策略时，跨域请求根本不会携带 Referer，服务端如果仅凭 Referer 是否存在来判断请求合法性，就会误伤正常用户。

防盗链的正确做法是结合多种手段。对于图片、视频等静态资源，可以使用 CDN 提供的鉴权机制，通过 URL 签名和时间戳来控制访问有效期。Nginx 的 secure_link 模块就能实现这个功能，生成包含过期时间和 MD5 签名的临时链接，即使链接被分享出去，超过有效期也会自动失效。

CSRF 防御更不能依赖 Referer 校验。业界标准方案是使用 CSRF Token，服务端生成随机 Token 嵌入表单隐藏字段或自定义 HTTP 请求头，请求提交时验证 Token 是否匹配。SameSite Cookie 属性也是强有力的补充，设置为 Lax 或 Strict 模式后，浏览器会自动禁止跨站请求携带 Cookie，从根源上阻断 CSRF 攻击。这两种方案与 Referrer Policy 配合使用，可以构建多层防御体系。

即使前端做了严格的 Referrer Policy 控制，网站自身的服务器日志中仍然会记录来自同源请求的完整 Referer 信息。这些日志文件如果被攻击者获取，同样能分析出网站结构、管理路径、用户行为模式。运维团队需要建立日志脱敏机制，在日志收集阶段就对 Referer 字段中的查询参数进行过滤或哈希处理。

使用 Nginx 可以直接在日志格式定义中剔除查询字符串。默认的 combined 日志格式使用 $request_uri 变量会记录完整 URL，改为 $uri 就只记录路径部分，不包含参数。如果需要保留参数用于分析但又要保护隐私，可以在日志处理管道中用正则表达式匹配敏感参数名，将其值替换为脱敏标记。

ELK 或 Splunk 等日志平台通常提供字段级的数据脱敏功能，可以配置规则自动识别 Referer 中的 token、session、password 等关键词，对对应值进行掩码处理。这样既保留了日志的可用性，又降低了数据泄露后的影响范围。

Referrer Policy 的浏览器兼容性已经相当好，主流浏览器包括各种国产浏览器的较新版本都完整支持。但企业环境中可能存在 IE11 或老旧 Chromium 内核的客户端，这些浏览器只支持部分策略值或者完全不支持。对于不支持的浏览器，它们会回退到自身的默认行为，通常是 always 模式，也就是始终发送完整 Referer。

为了覆盖这些遗留客户端，可以在服务端同时部署旧版的 Referrer Policy 元标签语法。HTML 标准曾经使用 <meta name="referrer" content="never"> 来表示 no-referrer，使用 <meta name="referrer" content="origin"> 来表示 origin 策略。虽然这些写法已被废弃，但老旧浏览器仍然能识别。配合新的 Referrer-Policy 响应头，可以做到新旧浏览器都能按预期执行。

测试 Referrer Policy 是否生效很简单。打开浏览器的开发者工具，切换到 Network 面板，发起一个跨域请求，然后查看该请求的 Request Headers 中是否有 Referer 字段以及字段的内容。也可以使用 curl 命令行工具模拟请求，curl -I -H "Referer: https://example.com/test" https://target-site.com 可以观察服务端返回的响应头。如果想批量检测全站链接的 Referer 泄露情况，可以使用爬虫工具遍历页面，收集所有外部资源的请求头信息。

网站信息泄露从来不是单一漏洞造成的，Referer 只是整个链条中的一环。把 Referrer Policy 配置好，把 URL 中的敏感参数清理干净，把日志脱敏做到位，这三件事结合起来才能构建起有效的来源信息防护体系。安全建设就是这样，不是做完一件大事就高枕无忧，而是把无数个看似不起眼的小问题都解决掉，攻击者的可乘之机才会被压缩到最小。