ie11不支持rel="noopener",需js兜底实现安全跳转;其忽略该属性,仍保留window.opener,存在钓鱼风险,必须通过window.open后置null或动态js控制来修复。

IE11 不支持 rel="noopener",但加了也不会报错;真正需要的是 fallback 逻辑或 polyfill 级别的兜底,而不是硬塞一个无效属性。
IE11 对 rel="noopener" 的实际表现
IE11 完全忽略 rel="noopener",既不启用安全隔离,也不抛错。这意味着:target="_blank" 链接在 IE11 中默认仍会继承 window.opener,攻击者可通过 window.opener.location = "https://evil.com" 重定向原页面——这是真实可利用的钓鱼链路。
验证方式很简单:在 IE11 控制台执行 console.log(window.opener),打开带 target="_blank" 的链接后,该值非 null。
- Chrome 49+、Firefox 52+、Edge 79+、Safari 12.1+ 均原生支持
noopener - IE11 是唯一主流但不支持的浏览器,且无计划修复(微软已终止支持)
-
rel="noreferrer"在 IE11 中虽被解析,但仅影响Referer头,不切断window.opener,所以不能替代noopener
兼容写法:不要只靠 HTML 属性
单纯在 <a></a> 标签里写 rel="noopener noreferrer" 对 IE11 无效。必须配合 JS 补偿:
- 对所有含
target="_blank"的外链,用 JS 动态设置rel并监听点击,调用window.open()替代原生跳转 - 在新页面中主动执行
window.opener = null(注意:只能在新页面 JS 中运行,且需确保脚本在window.opener被访问前执行) - 若使用
window.open(url, "_blank"),必须显式传入features字符串并确保不含opener(IE11 下即使不传 features,默认也会带 opener)
示例(安全跳转封装):
function safeOpen(url) {
if (window.navigator.userAgent.indexOf("MSIE ") > -1 || window.navigator.userAgent.indexOf("Trident/") > -1) {
const win = window.open("", "_blank");
win.opener = null;
win.location = url;
} else {
window.open(url, "_blank", "noopener,noreferrer");
}
}
ESLint 和 CMS 输出时的取舍
很多团队用 react/jsx-no-target-blank 规则强制加 rel="noopener noreferrer",这在现代浏览器中是合理的,但在纯 IE11 环境下反而制造虚假安全感。
- 服务端渲染(SSR)或 CMS 模板中,不应无条件注入
rel属性,而应判断 UA 或环境变量 - 若项目明确要求支持 IE11,建议关闭该 ESLint 规则,改用上面的 JS 封装函数统一管控
- 混合环境(如内网 IE11 + 外网 Chrome)下,
rel属性可保留(不干扰),但核心逻辑必须由 JS 承担
真正容易被忽略的点是:很多人以为加了 rel="noopener" 就万事大吉,结果在 IE11 里整个安全模型就塌了一角。它不是“多加一行更安全”,而是“不加 JS 就没安全”。











