referrerpolicy属性必须直接写在主动发起请求的HTML标签（如<iframe>、<img>、<script>等）上才生效，加在<meta>或<div>外层无效；它仅控制该元素触发的单次请求，且值大小写敏感，旧版Safari需后端响应头兜底。
referrerpolicy 属性必须直接写在
很多人把 referrerpolicy 加在 <meta name="referrer"> 里，或套在 <div> 外层，结果完全没用。它只对当前元素发起的 HTTP 请求起作用，且必须是直接挂载在 <iframe> 上——不是父页面、不是容器、不是 JS 动态插入后补的。
常见错误现象包括：第三方支付页仍能通过 document.referrer 拿到你页面完整路径；CDN 加载失败报 403；广告脚本上报时 Referer 带敏感 query 参数。
-
referrerpolicy值大小写敏感，写成"No-Referrer"或"origin-when-crossorigin"都会退化为默认策略no-referrer-when-downgrade - 旧版 Safari（≤15.4）直接忽略该属性，需配合服务端
Referrer-Policy响应头兜底 - 不能写成
<div referrerpolicy="no-referrer"><iframe src="..."></div>—— 属性不继承，也不冒泡
跨域 iframe 的 Referer 控制仅影响其内部请求，不影响父页加载它时的 Referer
这是最常被误解的一点：referrerpolicy="no-referrer" 放在 <iframe src="https://thirdparty.com/widget.html"> 上，只控制 widget.html 里面自己发的请求（比如它里面的 <img>、<script>），**不控制浏览器向 https://thirdparty.com/widget.html 发起的那次主文档请求**。
也就是说，父页面加载这个 iframe 时，HTTP 请求头里的 Referer 依然由父页面全局策略决定：优先级是 Referrer-Policy 响应头 > <meta name="referrer"> > 浏览器默认策略。
立即学习“前端免费学习笔记（深入）”；
- 若父页响应头没设
Referrer-Policy，且是 HTTPS 页面，默认发完整 URL（含 path 和 query），第三方可直接读取 - 验证是否生效，要打开 Network 面板，找到 iframe 的 HTML 请求（即
src指向的那个 URL），点开 Headers 查看 Referer 字段，而不是只看它内部加载的子资源 - 第三方若想隐藏来源，光靠前端加属性做不到，必须后端统一配响应头，例如 Nginx 中：
add_header Referrer-Policy "origin-when-cross-origin";
referrerpolicy 值选哪个？根据第三方行为定
不同值对隐私保护强度和功能兼容性有明显差异，不能一概而论。
-
no-referrer：最严，所有请求都不带 Referer，适合广告、统计类 iframe，但部分依赖 Referer 的 CDN 或校验逻辑会失败 -
origin：只发协议+域名+端口（如https://your-site.com），不带路径和 query，平衡安全与兼容，推荐作为默认选项 -
strict-origin-when-cross-origin：同域保留完整 Referer，跨域只发 origin，调试友好，但旧浏览器支持度略低 -
origin-when-cross-origin：Safari 旧版本兼容性更好，效果接近origin，但 HTTPS → HTTP 降级时仍会发 origin（有风险，慎用）
别忘了 sandbox 和 postMessage 的配合
referrerpolicy 只管 HTTP 请求头，不管 JS 运行时读取的 document.referrer 或 window.parent.location。恶意 iframe 仍可通过脚本拿到父页 URL。
- 必须搭配
sandbox="allow-scripts"（禁用allow-same-origin！），否则 iframe 内 JS 可读取父页 DOM 或 localStorage - 若需通信，
postMessage必须严格校验event.origin，禁止通配符*，且消息体需含签名字段防伪造 - 支付等高敏场景，
referrerpolicy="no-referrer"是 PCI DSS 合规硬性要求之一，漏配可能直接导致审计不通过
