iframe的referrerpolicy属性仅控制其内部发起的请求（如fetch、img、script）的Referer头，不影响父页面加载该iframe时的Referer；后者须由父页面HTTP响应头Referrer-Policy全局控制，如Nginx配置add_header Referrer-Policy "strict-origin-when-cross-origin" always;。
iframe 的 referrerpolicy 属性只管它自己发的请求
很多人加了 <iframe src="https://thirdparty.com/widget.html" referrerpolicy="no-referrer"> 就以为父页面来源被藏住了，结果第三方 widget 依然能拿到完整跳转路径——这是误解。referrerpolicy 只控制 iframe 内部 JS 发起的请求（比如 fetch()、<img src>、<script src>）的 Referer 头，**完全不影响父页面加载该 iframe 这个动作本身的 Referer**。
父页面加载 iframe 时的 Referer 怎么控制
这个 Referer 是由父页面的 HTTP 响应头决定的，不是 HTML 属性能改的。必须在服务端配置：Referrer-Policy: strict-origin-when-cross-origin。
Nginx 示例配置：
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
注意：always 参数不能省，否则 404/500 页面会退回到浏览器默认策略，反而泄露路径。
立即学习“前端免费学习笔记（深入）”；
- 不配响应头 → 浏览器用默认
no-referrer-when-downgrade，HTTPS → HTTPS 加载 iframe 时 Referer 是完整 URL（含?token=abc） - 配了但没
always→ 错误页不生效，风险集中暴露在异常路径上 -
<meta name="referrer">对 iframe 加载无效，它只影响后续 a 标签点击或 form 提交
referrerpolicy 必须直接写在 iframe 标签上才生效
不能写在包裹它的 <div> 或其他容器上，也不能靠 JS 动态设置属性后期望它“继承”生效——浏览器只认原生标签上的 referrerpolicy 属性。
常见错误写法：
-
<div referrerpolicy="no-referrer"><iframe src="..."></div>→ 完全无效 -
<iframe src="..."></iframe>后用 JS 设置iframe.referrerpolicy = "no-referrer"→ 不触发 Referer 裁剪逻辑 -
referrerpolicy="No-Referrer"或"no_referrer"→ 大小写/下划线错，被静默忽略
第三方 widget 读 window.parent.location 怎么办
referrerpolicy 对这个场景完全无解。它只控制 HTTP 请求头里的 Referer 字段，而 window.parent.location.href 或 document.referrer 是 JavaScript 可访问的 DOM 属性，和网络请求头无关。
HTML 层面没有机制能阻止子帧读取父帧 URL。如果敏感路径（如 /admin?token=xxx）出现在父页面地址栏里，且允许嵌入第三方 iframe，那隐私已实质暴露——此时真正该做的是：限制 iframe 嵌入（X-Frame-Options 或 Content-Security-Policy: frame-ancestors），或把敏感操作移出可嵌入页面。
