必须分层配合Referer校验与Referrer-Policy：前者是后端白名单验证，防盗链但不可信；后者是前端发送策略，从源头减少泄露，二者目标一致、机制不同，缺一不可。
要真正保护用户隐私并有效控制防盗链，不能只靠单一手段，必须把 Referer 的“泄露控制”和 Referrer-Policy 的“发送策略”分层配合使用——前者是后端校验逻辑，后者是前端发送规则，二者目标一致但作用机制完全不同。
明确 Referer 与 referrerpolicy 的分工
Referer 是请求头字段，本身不可信、可被伪造或省略；它只是浏览器“默认附带”的来源信息，不是身份凭证。而 referrerpolicy（注意拼写）是告诉浏览器“要不要发、发多少”，属于主动约束行为。
- 防盗链靠服务端检查
Referer请求头是否在白名单内，但它防不住空 Referer、伪造 Referer 或 HTTPS→HTTP 降级时的意外泄露 -
referrerpolicy属性或响应头能从源头减少敏感信息发出，比如不让支付结果页的?token=xxx跟着外链跳转出去 - 两者必须共存：没 referrerpolicy，Referer 泄露风险高；没 Referer 校验，盗链防护形同虚设
关键外链用 rel="noreferrer" 最简单可靠
对跳转到第三方网站的 标签，直接加 rel="noreferrer" 是最轻量、最彻底的方案：
- 它不只清 Referer，还隐式启用
noopener，防止新开页面通过window.opener反向控制原页（真实 XSS 风险） - 静态 HTML 也能生效，不依赖 JS，SEO 友好，所有现代浏览器（Chrome 51+、Firefox 50+ 等）都支持
- 右键“在新标签页打开”也受控——这点比
referrerpolicy="no-referrer"更强
资源加载与 iframe 嵌入需局部设 referrerpolicy
图片、脚本、iframe 等资源加载时也会自动带上 Referer，容易暴露当前页面路径。这时要在对应标签上显式声明：
-
-
：仅同源嵌入才传 Referer，跨源完全不发，避免 widget 服务商拿到你内部页面结构 - 注意：
referrerpolicy只对它所在的那个标签生效，不控制 JS 发起的fetch()或动态插入的元素
全局策略靠后端响应头，优先设 strict-origin-when-cross-origin
前端属性只能管 HTML 元素，真正的全覆盖必须靠服务器返回的 Referrer-Policy 响应头：
- 推荐值：
strict-origin-when-cross-origin——同域发完整 URL，跨域只发源（https://a.com），HTTPS→HTTP 降级时清空，隐私与功能平衡最佳 - 高度敏感页（如支付回调、含会话令牌的跳转）可用
no-referrer，但慎用，否则影响分析和部分跳转逻辑 - 绝对不要用
unsafe-url：它强制发完整 URL（含路径和参数），存在严重隐私风险，所有主流文档都明确禁止
防盗链配置要点（以 OSS / Nginx 为例）
Referer 校验是后端的事，不能指望前端策略替代：
- 白名单填可信域名，建议同时加
http://和https://版本，协议不匹配即拒绝 - 开启“不允许空 Referer”时，需确认是否允许用户直接访问（如分享链接进来的场景），否则可能误拦
- OSS 等云服务支持通配符（如
*.example.com）和截断 QueryString，配置时注意匹配精度 - 重要提醒：Referer 可被绕过，CSRF 防护、权限校验等核心逻辑绝不能依赖它是否存在
