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"> 就以为父页面来源被藏住了，结果第三方 widget 依然能拿到完整跳转路径——这是误解。这个属性只控制 iframe 内部 JS 加载图片、脚本、API 请求时的 Referer 头，比如它自己执行 <img src="https://cdn.example.com/ads.png"> 或 fetch("https://api.thirdparty.com/log")。父页面加载该 iframe 这个动作本身的 Referer，完全不受影响。
父页面加载 iframe 时的 Referer 怎么控制？靠响应头，不是 HTML 属性
要让 <iframe src="https://thirdparty.com/widget.html"> 这个请求不带敏感路径（比如 /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>上——referrerpolicy必须直接挂在<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 白名单兜底。
