iframe 的 referrerpolicy 仅控制其内部发起的请求（如 js 加载图片、api 调用）的 referer，不影响父页面加载 iframe 时发送的 referer；后者需通过父页面响应头 referrer-policy 控制，如 nginx 配置 add_header referrer-policy "strict-origin-when-cross-origin" always;。
iframe 的 referrerpolicy 只管它自己发的请求，不管父页面加载它时的 Referer
很多人加了 <iframe src="https://thirdparty.com/widget.html" referrerpolicy="no-referrer"></iframe> 就以为父页面来源被藏住了，结果第三方 widget 依然能拿到完整跳转路径——这是误解。这个属性只控制 iframe 内部 JS 加载图片、脚本、API 请求时的 Referer 头，比如它自己执行 <img src="https://cdn.example.com/ads.png?x-oss-process=image/resize,p_40"> 或 fetch("https://api.thirdparty.com/log")。父页面加载该 iframe 这个动作本身的 Referer，完全不受影响。
父页面加载 iframe 时的 Referer 怎么控制？靠响应头，不是 HTML 属性
要让 <iframe src="https://thirdparty.com/widget.html"></iframe> 这个请求不带敏感路径（比如 /admin?token=abc），必须在父页面的 HTTP 响应头里设：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 -
<meta name="referrer" content="origin">对 iframe 加载无效，它只影响后续 a 标签点击或 form 提交 - 不能把属性写在包裹 iframe 的
<div> 上——<code>referrerpolicy必须直接挂在<iframe></iframe>标签上才生效第三方 widget 读到 window.parent.location 怎么办？referrerpolicy 没用
referrerpolicy 控制的是 HTTP 请求头里的
Referer字段，而 widget 通过window.parent.location.href或document.referrer拿到的是 JavaScript 可访问的 DOM 属性，和请求头无关。这种情况下，HTML 层面无解。真正有效的做法是：- 要求第三方提供 sandboxed 版本（配合
sandbox="allow-scripts"等最小权限） - 用
srcdoc替代src，内联静态内容，彻底切断外部 JS 执行环境 - 服务端做代理中转，让 iframe 加载你自己的域名路径，再由后端转发并剥离敏感参数
验证是否真生效：别只看 iframe 里的子资源
调试时容易犯的错是盯着 iframe 里一张图片的 Network 请求看
Referer是否为空。真正该查的是 iframe 主文档本身那条请求——也就是src指向的 HTML 文件的加载请求。这条请求的Referer头才是父页面暴露与否的关键。打开 Chrome DevTools → Network → 找到对应 iframe 的 HTML 请求 → 点开 Headers → 查Request Headers里的Referer行。如果策略正确，跨源时它应该只有协议+域名+端口，不含路径和查询参数。旧版 Safari（≤15.4）会直接忽略
referrerpolicy，所以对关键业务，不能只依赖前端属性，得和服务端 Referer 白名单兜底。 - 要求第三方提供 sandboxed 版本（配合
