必须显式写rel="noopener"，因为现代浏览器默认保留window.opener引用，将其设为null需开发者主动声明，noreferrer不切断opener，无法替代noopener。
不加 rel="noopener" 的 target="_blank" 链接，等于把原页面的控制权白送给新页面——攻击者一行 window.opener.location = 'https://fake-login.example' 就能劫持你的整个标签页。
为什么必须显式写 noopener，不能只靠浏览器默认？
现代浏览器（Chrome 88+、Firefox 79+、Safari 14.1+）仍默认保留 window.opener 引用，除非你明确声明 rel="noopener"。这不是兼容性问题，是设计如此：浏览器把“是否切断 opener”当作开发者主动的安全决策，而非自动防护。
常见错误现象：
- 写了
target="_blank"却漏掉rel属性，页面上线后被扫描工具标为高危 - 只写
rel="noreferrer"，误以为它等价于noopener；但旧版 Safari（noreferrer 不保证window.opener === null - 在富文本编辑器或 CMS 输出中，用户粘贴的链接自动带
target="_blank"，但服务端未做rel补全
rel="noopener noreferrer" 中两个值到底谁管什么？
noopener 是核心防御项，强制新页面的 window.opener 为 null，彻底阻断劫持链；noreferrer 是补充项，同时禁用 Referer 请求头，并在多数现代浏览器中隐式触发 noopener 行为——但它不可替代前者。
立即学习“前端免费学习笔记（深入）”；
使用建议：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 外部链接一律用
rel="noopener noreferrer"，语义清晰、覆盖全面 - 如果业务强依赖
Referer（如来源统计），至少保留rel="noopener"，不要为了 Referer 放弃安全底线 - 不要写成
rel="noreferrer noopener"顺序颠倒——虽然浏览器通常忽略顺序，但部分解析器（如某些 Markdown 渲染器）可能按顺序处理，优先取第一个合法值
JavaScript 动态开窗时怎么防 opener 劫持？
用 window.open() 模拟 target="_blank" 时，仅靠参数字符串不够可靠。不同浏览器对 opener: null 的支持程度不一，最稳的方式是显式传入 features 字符串并包含 noopener。
正确写法示例：
<a href="#" onclick="window.open('https://example.com', '_blank', 'noopener'); return false;">安全外链</a>
容易踩的坑：
-
window.open(url, '_blank')—— ❌ 没有noopener，依然存在 opener 引用 -
window.open(url, '_blank', 'opener=null')—— ❌ 错误语法，浏览器不识别 - 用
rel+target能解决的问题，别硬切到 JS 开窗；HTML 原生方案更轻量、无 JS 降级风险、SEO 友好
服务端或前端自动补全 rel 属性的实操要点
对用户生成内容（UGC）或 CMS 管理的页面，手动加 rel 极易遗漏。推荐在 HTML 渲染环节统一注入，但要注意合并逻辑。
关键判断条件：
- 匹配所有含
target="_blank"的<a>标签 - 若已有
rel属性，检查是否已含noopener；未包含则追加，不要覆盖（例如rel="nofollow"→ 应转为rel="nofollow noopener noreferrer"） - 避免重复注入：同一链接多次处理可能导致
rel="noopener noopener"这类冗余 - 注意 XSS 风险：补全逻辑必须在服务端或可信上下文中执行，不能依赖不可信的前端 DOM 操作
真正麻烦的不是加属性本身，而是如何在不破坏已有语义（比如 rel="canonical" 或 rel="author"）的前提下，精准识别、安全合并——这需要正则足够健壮，或用 HTML 解析器（如 jsdom、cheerio）做 AST 级操作。
