What is noopener?
noopener is a value for the rel attribute on HTML links. It modifies what happens when a user clicks a link that opens in a new tab.
When you write <a href="..." target="_blank">, the destination page gets a back-reference to the page that opened it via window.opener. rel="noopener" removes that back-reference, so the new page can't reach back into the original.
Why it matters
Tabnabbing. Without noopener, the destination page can run window.opener.location = "https://phishing.example/" and silently navigate the original tab to a fake login page. The user clicks a link, switches tabs, comes back, and sees what looks like the original site asking them to "log in again." It's a real attack pattern, and the fix is one attribute.
Performance. With noopener, the new tab can run in its own process. Without it, both tabs share a process and a heavy script in the new tab can block your site. On older or slower devices the difference is visible.
Modern browser default. Since 2021, Chrome, Firefox, and Safari treat target="_blank" as implicitly noopener even if you don't write it. The security half is mostly handled for you. You still want to write the attribute explicitly because:
- Older browsers and embedded WebViews don't always apply the default
- Static analysis tools (ESLint plugins, accessibility linters) flag the missing attribute
- It signals intent to the next person reading your HTML
How it actually works
<a href="https://example.com/" target="_blank" rel="noopener">
Example
</a>
The destination page now sees window.opener === null and cannot manipulate the original tab.
noopener is often paired with noreferrer as rel="noopener noreferrer". The two solve different problems: noopener blocks window.opener access, noreferrer strips the Referer header. noreferrer also implies noopener in modern browsers, but writing both is the convention because it makes the intent obvious in markup and stays correct in older browsers and embedded WebViews.
Common mistakes:
- Forgetting
noopenerontarget="_blank"links generated dynamically by JavaScript (the static markup is fine, the JS-injected links are not) - Using
rel="opener"(this re-enables what the default disables and is almost always wrong) - Adding
noopenerto internal same-origin links where it has no security benefit and adds noise
How webentity handles this
Across a webentity codebase, every target="_blank" link is rendered with rel="noopener noreferrer". The convention is applied at every call site - navigation, footers, comparison tables, case studies, audit reports - so a missing rel attribute stands out in review and never ships to production.
The result: no tabnabbing surface to clean up later, and no late-arriving security scan finding from an automated audit.