// TL;DR
Reverse tabnabbing has a well-known fix: a site adds rel=”noopener” to its outbound target=”_blank” links, which stops the opened page from controlling the original tab. I found that Microsoft Edge didn’t honour rel=”noopener” — so even a site that did everything right was still exploitable in Edge. A page opened from a link could redirect the user’s original tab to an attacker’s site, because the browser itself failed to sever the window.opener reference the way Chrome and Firefox did.
Quick recap: reverse tabnabbing
When a page opens a new tab via target="_blank" (or window.open()), the browser normally hands the newly opened page a window.opener reference back to the page that launched it. A malicious opened page can abuse that reference to redirect the original tab — for instance, to a fake login — while the user is distracted reading the new tab. That’s reverse tabnabbing.
The standard defence lives on the website: add rel="noopener" to outbound blank-target links, and the opened page gets window.opener === null, so it can’t touch the opener. (If you want the full mechanism, see the main tabnabbing article.)
The finding: Edge ignored the fix
Here’s the problem I found: Microsoft Edge did not respect rel="noopener".
That flips the responsibility in a nasty way. Reverse tabnabbing is supposed to be a site-side issue — a site that adds noopener is protected. But if the browser doesn’t enforce the attribute, then the protection silently does nothing, and users of that browser are exposed even on sites that implemented the fix correctly.
In testing, a page opened from a link in Edge could still reach back and redirect the original tab to another site — demonstrating that the opener reference was never severed, despite the attribute that should have severed it. The same test on Chrome and Firefox behaved correctly (the redirect was blocked), which isolated the failure to Edge.
Why this is worse than a site bug
A single vulnerable website affects that one site’s users. A browser that ignores noopener affects every site its users visit:
- It defeats a fix sites already deployed. Developers who did the right thing get no protection for their Edge users, through no fault of their own.
- It’s invisible. Nobody auditing the website would catch it — the markup is correct. The failure is one layer down, in the browser’s handling of it.
- It scales to the whole browser population. The exposure isn’t “this site is vulnerable,” it’s “this browser’s users are vulnerable across the web.”
That’s what makes a browser-level regression of a standard security control more serious than its “medium” label might suggest.
The real fix
For the browser, the fix is simply to honour rel="noopener" (and the related noreferrer) as the standard requires, severing window.opener for links that declare it.
For site developers — who can’t control which browser a visitor uses — the practical hardening is to use the complete relationship attribute on outbound blank-target links rather than relying on any single token or on browser defaults:
<a href="https://external-site.example" target="_blank" rel="nofollow noopener noreferrer">
Visit site
</a>
noopener severs the opener reference, noreferrer additionally strips the referrer (and implies noopener in older engines), and including both maximises the chance the protection holds across inconsistent browser implementations like this one.
And for users: the old advice still applies — if a background tab suddenly shows a login page, don’t trust it. Close it and reopen the site fresh from a bookmark or by typing the address, and check the address bar before entering credentials.
Thanks for reading — and keep an eye on your tabs. Happy hacking!
Leave a Reply