rel="noopener"通过浏览器在解析阶段直接将新页面的window.opener设为null，从源头切断引用链，而非运行时拦截；它必须与target="_blank"配合使用才生效，且不可被noreferrer替代。
rel="noopener"如何切断window.opener引用
它不是“阻止”或“过滤”某个行为，而是直接让新页面的window.opener值为null。浏览器在解析到rel="noopener"时，会在创建新浏览上下文（即新标签页）阶段就跳过设置opener字段这一步——相当于从源头上不建立这个引用链。
没有这个引用，攻击者连window.opener都取不到，更别说调用window.opener.location.replace()或window.opener.postMessage()了。这不是靠运行时拦截，是构造阶段的隔离。
- 只加
target="_blank"：新页面window.opener指向原页面window对象，可任意读写 - 加
rel="noopener"：新页面window.opener === null，访问即返回null，任何赋值或方法调用都无效 -
rel="noreferrer"不影响window.opener，它只控制HTTP请求头中的Referer字段是否发送
为什么不能只依赖现代浏览器的隐式noopener
Chrome ≥64、Firefox ≥79 等确实对target="_blank"做了隐式noopener处理，但这个行为仅限于“无其他rel值”的干净场景。一旦你写了rel="nofollow"或rel="external"，隐式机制就失效——浏览器会按字面解析，忽略未声明的noopener。
- Safari ≤12.0 完全不支持隐式
noopener，必须显式声明 - 某些旧版 WebView（如 Android 8.0 内置 WebView）也不生效
- Lighthouse、axe 等审计工具仍会把缺失
rel="noopener"标为中高危项，因为合规性不看“多数人用了什么”，而看“有没有确定性防护”
rel="noopener noreferrer"组合使用的实际影响
两者解决的是不同维度的问题，合用是常见实践，但需清楚各自作用边界：
-
rel="noopener"：安全底线，防window.opener劫持，必须加 -
rel="noreferrer"：隐私补充，使跳转请求不带Referer头，避免泄露来源路径（比如/admin/users?id=123） - 注意：
noreferrer会让document.referrer在目标页也为空，如果对方页面依赖该字段做来源统计或白名单校验，可能出问题 - 性能上，
noopener确实有轻微收益：浏览器不用维持两个页面间的上下文关联，内存占用略低
window.open()调用时怎么等效防护
<a></a>标签靠rel属性，window.open()就得手动干预。它默认也会设opener引用，必须显式切断：
错误写法：window.open('https://evil.com', '_blank') → 新页面仍可访问window.opener
正确写法：window.open('https://evil.com', '_blank', 'noopener') → 第三个参数传'noopener'字符串（注意不是rel属性）
或者更彻底：const w = window.open('https://evil.com', '_blank'); w.opener = null; —— 但要注意跨域限制：若目标页同源，这行赋值有效；若跨域，浏览器会抛DOMException，所以优先用'noopener'参数方式
最容易被忽略的一点：只要用了target="_blank"，无论链接指向文档、帮助页还是自家子域名，都必须加rel="noopener"。攻击不依赖同源，也不需要用户停留或交互——页面一加载，window.opener.location = '...'就能静默执行。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
