Reverse Tabnabbing is a browser attack where a newly opened page gains control of the opener window and redirects it to a fake site. It is usually abused through links that open in a new tab without protective attributes. Defenders should use rel=”noopener” or rel=”noreferrer” on external links opened in new tabs.
How reverse tabnabbing works
Reverse tabnabbing depends on a specific browser relationship: the newly opened page can still reach back into the opener window unless the link is isolated. That makes the attack less about the destination page itself and more about the trust the original page gives to an external site opened in a new tab.
In practice, the dangerous pattern is a link that uses a new browsing context without protective attributes. Once the user is on the external page, that page can attempt to replace the opener with a convincing clone, which is why the weakness is often described as a trust-boundary failure in the browser rather than a server-side exploit.
Why it is dangerous
The core danger is user deception at the moment the browser still treats the original page as reachable. A legitimate page can be turned into a launch point for phishing, account takeover, or payment redirection simply because the user trusted the first tab and then returned to a tampered one.
This matters most on sites that routinely send users to third-party destinations, including login flows, documentation portals, payment providers, and partner sites. If the opener can be rewritten, the attacker does not need to compromise the original application directly; they only need the browser relationship created by the outbound link.
What protects against it
The standard defence is to break the opener relationship on outbound links that open in a new tab. The most common controls are rel="noopener" and, where appropriate, rel="noreferrer", which prevent the new page from controlling the source window and reduce the chance of opener-based redirection.
Because the issue lives in client-side link handling, it belongs in frontend review, content security review, and secure markup templates rather than in server-side routing logic. NHIMG’s Client-Side Security Guide is a useful companion reference for adjacent browser-side risks such as third-party script exposure, DOM manipulation, and other client-side trust failures.
Teams should also treat rich-text editors, CMS output, markdown renderers, and user-generated content as places where unsafe link attributes can be introduced at scale. A safe default in templates is more reliable than expecting every author to remember the right attributes every time.
Where to check and how to verify
Organisations usually find this issue by reviewing outbound links that open in a new tab, then checking whether the generated HTML consistently applies protective attributes. That review should include production templates, marketing pages, help centres, and any content pipeline that lets editors publish links without code review.
Verification is straightforward: inspect rendered markup, test browser behaviour on external destinations, and confirm that the opener is not available to the new page. This is especially important after CMS changes, frontend framework upgrades, or content migrations, when link rendering rules can drift without being noticed.
In larger estates, browser-side protection works best when paired with security review of generated HTML and third-party content handling. The most dependable fix is one that is built into the platform, not one that relies on authors remembering an exception during publication.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-16 — Application Software Security | Reverse tabnabbing is a client-side web security issue that should be prevented through secure link handling and review. |
| Recommendation — Review rendered links and enforce safe outbound-link attributes in application templates and content pipelines. | ||
| OWASP ASVS | V3 — Web Frontend Security | The weakness is created and mitigated in browser-rendered frontend content and link behaviour. |
| Recommendation — Validate frontend rendering rules so external links opened in new tabs cannot control the opener window. | ||
| NIST SP 800-53 Rev 5 | SC-18 — Mobile Code | This browser-based attack arises from untrusted client-delivered content and unsafe execution context handling. |
| Recommendation — Restrict unsafe client-side content patterns that allow untrusted pages to influence the original browsing context. | ||