Referrer-Policy是防止敏感参数通过Referer泄露最直接有效的手段，通过Nginx响应头配置strict-origin-when-cross-origin策略，可使同源发完整URL、跨域HTTPS仅发源、HTTPS→HTTP不发送，配合always参数确保全响应生效。
Referrer-Policy 是防止敏感参数通过 Referer 泄露最直接、最有效的手段之一。它不依赖前端代码改造，也不需要修改业务逻辑，只需在 Nginx 响应头中正确配置，就能让浏览器自动裁剪掉 URL 中的危险部分（比如 user_id=12345、token=abcde、/admin/ 路径等），从根本上切断信息外泄通道。
为什么 Referer 会泄露敏感参数？
浏览器默认行为是：从 A 页面跳转到 B 页面时，把 A 的完整 URL 写进 Referer 请求头发给 B。如果 A 是 https://example.com/user/profile?uid=8899&session=xyz，而用户恰好点击了一个跳往第三方统计平台的链接，这个带 uid 和 session 的完整地址就可能被记录下来。
常见高危场景包括：
- 管理后台页面跳转至外部帮助文档或客服系统
- 用户中心页嵌入第三方分享按钮（微博、微信 JS-SDK）
- 单页应用（SPA）路由含 query 参数，再触发跨域资源请求（如图片、脚本、iframe）
- 未做 referer 过滤的登录成功页重定向到合作方网站
推荐策略：strict-origin-when-cross-origin
这是当前兼顾安全性与功能可用性的最优解。它的行为清晰、可预测，且被主流浏览器广泛支持（Chrome 64+、Firefox 69+、Safari 15.4+）：
- 同源请求（例如
https://a.com/page1→https://a.com/page2）：发送完整 URL - 跨域 HTTPS→HTTPS（例如
https://a.com→https://b.com）：只发送源（https://a.com），丢弃路径和参数 - 跨域 HTTPS→HTTP（降级）：完全不发送 Referer
这意味着，即使你的用户详情页 URL 是 https://app.example.com/user?id=7788&tab=security，当它跳转到第三方站点时，对方收到的 Referer 只有 https://app.example.com，敏感参数全部被剥离。
Nginx 配置方式与注意事项
在 server 或 location 块中添加响应头即可，务必带上 always 参数，确保 4xx/5xx 错误页也受控：
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
常见错误要避开：
- 漏写
always：Nginx 默认只对 2xx/3xx 响应加头，错误页会退回到浏览器默认策略（通常是no-referrer-when-downgrade） - 写在 if 块里：Nginx 不允许在 if 中使用 add_header，会导致配置失效
- 多个 add_header 冲突：后写的会覆盖前写的，建议统一放在全局 server 块末尾
- 与前端 meta 标签共存：服务端 header 优先级高于
，但两者混用易引发调试困惑，建议以 Nginx 配置为准
如何验证是否生效？
打开浏览器开发者工具 → Network → 点击任意跨域链接 → 查看请求的 Request Headers → 找到 Referer 字段内容。同时检查响应头中是否有 Referrer-Policy: strict-origin-when-cross-origin。
更稳妥的方式是用 curl 检查：
curl -I https://your-site.com/
输出中应包含：
Referrer-Policy: strict-origin-when-cross-origin
若没看到，说明配置未加载成功，需检查 Nginx 配置语法、是否重载服务（nginx -s reload）、是否被其他模块（如 proxy_pass 后端）覆盖响应头。
