In one paragraph
A target="_blank" link without rel="noopener" lacks an explicit instruction to sever the opened page's opener reference. Modern browsers generally apply that behaviour implicitly to such links, so the residual risk depends on client support and context. Add noopener where no opener relationship is needed, and test deliberate popup integrations. Use noreferrer separately when you also intend to suppress referrer information.
Why it matters
Reverse tabnabbing abuses an opened page's reference to the original window. In susceptible contexts, the opened page can navigate that window to a deceptive destination while the visitor is looking elsewhere. This does not require the original site's content to be compromised.
Current browser handling of ordinary target="_blank" links largely reduces that historical risk by implying noopener unless an opener relationship is deliberately requested. Older clients and embedded webviews can differ. Explicit markup remains useful, but avoid describing every missing token as a live high-severity exploit for all visitors.
noopener and noreferrer have related but different purposes. noreferrer suppresses the Referer information and also implies opener isolation in relevant browser behaviour. Adding it unnecessarily can remove attribution expected by a partner. A link needing only opener separation can use noopener alone.
How WebAuditOS evaluates this finding
The supplied rule inspects anchor links in served HTML that open another hostname with target="_blank", ignoring a leading www in its host comparison. A literal noopener token in rel passes; missing tokens warn at low severity. No eligible link is not graded.
It does not inspect window.open calls, form targets, area elements, or links created later by JavaScript. It does not count noreferrer alone as satisfying the rule, despite that token's browser effect. Internal-host links are skipped by this check, not certified harmless: same-origin trust and future navigation still deserve intentional design.
How to fix it
- Review each flagged link and decide whether a new tab is useful. Removing an unnecessary target can simplify navigation. Where a new browsing context remains intended, determine whether any real workflow needs an opener reference.
- For an ordinary external link with no such dependency, add the explicit token:
<a href="https://partner.example.com/" target="_blank" rel="noopener">Partner documentation</a>Preserve existing appropriate rel tokens, such as sponsored or ugc where relevant. Do not replace the whole attribute with a single token and silently discard other intended metadata.
- Add noreferrer only when suppressing referrer information is deliberate. If a partner depends on referral attribution, use noopener alone and manage referrer behaviour through the appropriate policy rather than copying a combined value indiscriminately.
- Fix shared link components or CMS rendering rules so future links inherit the intended behaviour. Review menus, user-generated content, and older saved rich text as well as new editor output. Sanitize untrusted URLs and markup independently of opener settings.
- Search for explicit rel="opener" and JavaScript window.open usage separately. This scanner does not cover every opening mechanism, and a script API can require its own explicit noopener feature or integration-specific design.
- Test real OAuth, payment, or other popup workflows before changing communication assumptions. A flow that expects window.opener.postMessage can stop completing when the relationship is severed. Follow the provider's supported design and validate message origin and content; do not preserve an unnecessary powerful relationship merely to avoid investigation.
- Check the final rendered anchor and browser behaviour in supported clients. Confirm the normal destination, new-tab behaviour where intended, and any expected attribution. Review accessibility implications of unexpectedly opening windows.
- Rescan the served HTML, retaining separate coverage for runtime links and popup code. A passing token test is not a complete navigation or cross-window security review.
What the fix can break
Legitimate opener-based communication can fail silently even while the popup completes its task. Test success, cancellation, and return-to-application behaviour, not merely that a new window opens.
Adding noreferrer can change the destination's attribution. That is distinct from the intended noopener protection and should be a conscious privacy decision.
Text-based analytics and component tests can also be affected by broader link refactoring. Keep this change targeted: protect the relationship without unnecessarily changing URLs, labels, or business tracking requirements.
Questions
Do modern browsers already imply noopener?
Generally for ordinary target="_blank" links, yes. Explicit markup still states intent and can help older supported clients. Do not generalise that default to every script-opened window.
Is noreferrer alone enough for browser opener isolation?
It can provide that effect, but the supplied rule specifically looks for noopener. Adding the token can satisfy the check without changing an already intentional referrer decision.
Should every external link open a new tab?
No. Choose navigation behaviour for the user and task. Noopener is not a reason to add unnecessary new-window navigation.
Which related pages help?
Review COOP and Referrer-Policy, which address related but distinct controls.