rel属性noopener与noreferrer区别：外链安全打开技巧

对于外链添加 rel="noopener noreferrer" 这一组合，许多开发团队已形成“写上总没错”的惯性。技术世界最需要警惕的正是这种惯性——新旧标准更迭、浏览器行为升级，都可能让曾经的“最佳实践”变成冗余代码。本文从实际效果出发，完整解析该属性的真实作用。

目前给外链添加 rel="noopener noreferrer" 已非必须操作，但不等于可以随意删除——关键取决于目标浏览器范围、是否使用 HTTPS，以及是否在意 referrer 数据丢失。

为何 rel="noopener" 不再强制要求

自2021年起，Chrome、Firefox、Edge 等主流浏览器已默认对 target="_blank" 的链接启用 noopener 行为。即使用户代码中未写该属性，window.opener 实际也已为 null，新页面无法通过该接口将源页面劫持到恶意地址。

这意味着：

• 手动添加 rel="noopener" 仅增加 HTML 体积，安全提升基本为零。
• 老旧浏览器（如 IE、旧版 Safari）仍需该属性保底，但当前此类用户占比极低，多数项目可忽略。
• WordPress 等 CMS 默认插入该属性，属于历史惯性，并非当前安全刚需。

rel="noreferrer" 真实影响 referrer 数据

该属性作用为主动清空 Referer HTTP 请求头和 document.referrer JS 属性。与 noopener 不同，浏览器不会兜底——未写该属性时正常发送 referrer，写了则一定不发送，无商量余地。

具体后果包括：

• 在 Google Analytics 或其他统计工具中，点击该链接带来的流量会被归为“直接访问”，而非“引荐流量”，来源分析数据断环。
• 若业务依赖 referrer 做渠道归因、A/B 测试分流等判断，添加 noreferrer 等于主动丢失宝贵数据源。
• HTTPS 站点之间本身不会泄露路径级 referrer（仅传 origin），因此该属性对隐私提升相当有限。

是否应统一写成 rel="noopener noreferrer"

组合写法虽常见，但需清晰拆解每部分的作用：

• noopener：现代浏览器下纯属冗余，仅兼容旧环境。若明确支持 Chrome 90+、Firefox 85+，可完全省略。
• noreferrer：真实生效，但会切断 referrer 传递。若 SEO 或运营分析需要准确来源信息，则不应添加。
• 二者无功能重叠。noreferrer 并不等价于 noopener——在不支持 noopener 的老版浏览器中，仅靠 noreferrer 无法阻止 window.opener 访问。

更务实的做法是：外链统一使用 target="_blank"，不加任何 rel；仅在明确需要隐藏 referrer 的场景（如跳转到敏感合作方页面）时，单独添加 rel="noreferrer"。

真正容易被忽略的是：许多团队将 rel="noopener noreferrer" 视为安全标配批量注入，却未思考是否真正需要。尤其当 referrer 数据是归因链条中的关键一环时，添加该属性反而破坏数据闭环。与其绕弯路，不如从一开始保持清醒判断。