必须显式设置Referrer-Policy，因默认no-referrer-when-downgrade在HTTPS→HTTPS跳转时仍透出含token或/admin路径的完整URL；strict-origin-when-cross-origin是合理起点，同源发全URL、跨源仅发origin、HTTPS→HTTP不发，兼顾统计与隐私。
Referrer-Policy 不是装饰性标签，它直接决定浏览器在跳转、资源加载、iframe 嵌入等场景下是否发送 Referer 请求头——而这个字段常含敏感路径、查询参数甚至 token。设为不当，就等于把用户行为日志主动推给第三方。
什么时候必须显式设置 Referrer-Policy？
默认策略（no-referrer-when-downgrade）在 HTTPS → HTTP 跳转时清空 Referer，看似安全，但存在明显缺口：
- HTTPS → HTTPS 跳转仍完整透出原始 URL，含
?token=abc123或/admin/user/456等路径 - 页面内
<img src="https://cdn.example.com/track.png?uid=789">会把当前页 URL 当作Referer发给 CDN 域名 -
<iframe src="https://third-party.com/widget">允许被嵌入方读取父页 URL（除非子帧自身也设策略）
strict-origin-when-cross-origin 是多数站点的合理起点
它在同源请求中保留完整 Referer（利于内部统计），跨域时只发 origin（如 https://a.com），且降级时（HTTPS→HTTP）不发任何内容。比 no-referrer 更平衡，比默认策略更收敛。
设置方式有三处，优先级从高到低：
立即学习“前端免费学习笔记（深入）”；
- HTTP 响应头：
Referrer-Policy: strict-origin-when-cross-origin（推荐，覆盖所有资源） -
<meta name="referrer" content="strict-origin-when-cross-origin">（仅作用于当前 HTML 文档发起的请求，不控制 CSS/JS 中的 fetch） -
<a href="..." referrerpolicy="no-referrer">或<img referrerpolicy="origin">（单点覆盖，适合特殊外链或埋点图）
哪些资源特别容易暴露路径？如何针对性拦截
图片、字体、脚本、iframe 这几类资源若托管在独立域名（尤其 CDN 或 SaaS 服务），其请求头中的 Referer 往往泄露内部路由结构。例如：
<link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Inter">
该请求的 Referer 是你当前页完整 URL，Google Fonts 就能知道用户正在访问 /dashboard/settings/billing。
应对方式不是禁用资源，而是收紧策略：
- 对所有外域资源，统一用
Referrer-Policy: origin响应头（只发协议+域名） - 若使用
fetch()加载 API，显式传{referrerPolicy: 'no-referrer'}，避免后端日志记录调用来源 - 避免在 query 参数中传递敏感标识；改用
POSTbody 或 header 传 token，因Referer不包含 body 和 header
测试与验证：别信文档，要看真实请求头
浏览器开发者工具的 Network 面板里，点击任意跨域请求 → Headers → Request Headers → Referer 字段，才是最终生效结果。常见误判点：
- 本地
file://打开 HTML 时，<meta>不生效（需起本地 server） - Service Worker 拦截并重发请求时，
Referer可能被重写或丢失，需检查event.request.referrer - Chrome 扩展或某些企业代理可能强制覆盖策略，生产环境务必用真实终端抓包确认
最易被忽略的是：策略对 302 重定向链中中间跳转无效——第一个跳转按原策略发 Referer，后续跳转由目标服务器响应头决定。隐私敏感路径，应避免用 302 暴露中间态。
