How is reverse tabnabbing relevant to mobile apps?

Because it is web behavior, it matters wherever your app renders web content in a WebView. If that content opens links into new windows or external contexts and the WebView or content does not enforce the noopener protection, reverse tabnabbing can occur, letting an opened page redirect the page the user trusts. Modern browsers now default target=_blank to behave as noopener, mitigating the classic case in a browser, but you should not assume a WebView, or older or custom content, applies that default, so in a hybrid or WebView-using app the protection is something to ensure rather than assume.

Do modern browsers already prevent reverse tabnabbing?

Largely, in browsers: modern browsers default target=_blank links to behave as noopener, which severs the window.opener reference and mitigates the classic case. But you should not rely on that default inside a WebView, which may not apply it, and explicit window.open calls or content you do not fully control can still be exposed depending on the engine and configuration. So for app web content rendered in a WebView, enforce the protection explicitly rather than assuming the browser default carries over, and govern how the WebView handles new-window navigation.

How do I prevent reverse tabnabbing?

Sever the opener reference. For any link that opens a new context, add rel=noopener noreferrer, which prevents the opened page from receiving a usable window.opener and from leaking the referrer, and when opening windows programmatically use the noopener behavior. Apply this to the web content your app controls rather than relying on browser defaults inside a WebView. For the WebView itself, control how new windows and navigations are handled and validate where links may go, especially for user-supplied or third-party content, as part of your broader WebView hardening.

Reverse tabnabbing in mobile WebViews

Reverse tabnabbing is a sneaky web flaw that follows web content into mobile apps. When a page opens a link in a new context without the right protection, the page that opens, which could be attacker-controlled, gets a reference back to the opener and can quietly redirect it, for example to a phishing copy of your login. The user, looking at the new page, does not see that the page they came from has changed underneath them. Modern browsers default to blocking this, but WebViews and hybrid app content do not always, so if your app shows web content that opens links, it is worth handling. Here is what reverse tabnabbing is and how to prevent it in mobile WebViews.

Short answer

Reverse tabnabbing is a vulnerability where a page that opens a link in a new context, via target="_blank" or window.open, without the noopener protection, gives the newly opened page a reference back to the opener through window.opener, letting that page redirect the original one, typically to a phishing site. Per OWASP, the fix is to add rel="noopener noreferrer" to such links and use noopener with window.open, so the opened page cannot reach the opener. It is relevant to mobile apps that display web content in a WebView, where the protective browser defaults may not apply, so the WebView and the content it loads should enforce noopener and control how new windows are handled. Sever the opener reference for links that open new contexts.

What you should know

Reverse tabnabbing lets an opened page redirect the opener: via window.opener.
It comes from opening links without noopener: target="_blank" or window.open.
The opened page can be malicious: and quietly navigate the original.
Browser defaults help, WebViews may not: enforce it in app web content.
The fix is rel="noopener noreferrer": and controlling new-window handling.

What is reverse tabnabbing?

It is an opened page abusing a reference back to the page that opened it. When a web page opens a link in a new context, with target="_blank" or window.open, the newly opened page may, unless prevented, receive a reference to the opener through window.opener. If the opened page is attacker-controlled, perhaps a third-party or user-supplied link, it can use that reference to change the opener's location, redirecting the original page to a destination of its choosing while the user is focused on the new page. The classic exploitation is phishing: the original page is silently navigated to a convincing fake of itself, so when the user returns to it, they are actually on the attacker's copy and may re-enter credentials. It is called reverse tabnabbing because the influence runs backward, from the newly opened page to the one that opened it, the opposite of the opener controlling the child. The root issue is that opening a link can hand the destination a reference back to your page.

How does it work, and what is the mobile angle?

Through the opener reference, and it follows web content into WebViews. The table outlines it.

Element	Detail
Trigger	A link opened with `target="_blank"` or `window.open`
Missing protection	No `noopener`, so `window.opener` is available
Abuse	The opened page redirects the opener via that reference
Impact	The original page silently navigated, often to phishing
Mobile angle	WebView content where protective defaults may not apply

The mechanics are that opening a new context without noopener leaves window.opener accessible to the opened page, which then sets the opener's location to redirect it. The impact is a stealthy redirect of the page the user trusts, commonly to a phishing site. The mobile angle is that this is web behavior, so it matters wherever your app renders web content in a WebView: if that content opens links into new windows or external contexts, and the WebView or content does not enforce the protection, reverse tabnabbing can occur. Modern browsers now default target="_blank" to behave as noopener, which mitigates the classic case in a browser, but you should not assume a WebView, or older or custom content, applies that default, and explicit window.open or content you do not fully control can still be exposed. So in a hybrid or WebView-using app, the protection is something to ensure rather than assume.

How do you prevent it?

Sever the opener reference, and control how the WebView opens links. For any link that opens a new context, add rel="noopener noreferrer", which prevents the opened page from receiving a usable window.opener and from leaking the referrer, and when opening windows programmatically use the noopener behavior so the new window cannot reach the opener. Apply this to the web content your app controls, and do not rely on browser defaults inside a WebView. For the WebView itself, control how new windows and navigations are handled, deciding which links may open and how, rather than blindly allowing arbitrary new-window creation, and validate or restrict where links can go, especially for user-supplied or third-party content. Combine this with your broader WebView hardening, restricting what the WebView can load and execute, since reverse tabnabbing is one of several web-content risks. The principle is that opening a link should never hand the destination control over your page, so cut the opener reference with noopener and govern new-window behavior in the WebView, particularly for content you do not fully trust.

What to watch out for

The first trap is links that open new contexts without noopener in WebView content, letting an opened page redirect your page to phishing; add rel="noopener noreferrer" and use noopener with window.open. The second is assuming a WebView applies the browser's protective default, when it may not, so enforce it explicitly. The third is allowing arbitrary new-window navigation in the WebView without controlling or validating it. WebView and content handling is configured in your app, so a pre-submission scan such as PTKD.com (https://ptkd.com), which reads the compiled app against OWASP MASVS, surfaces your WebView configuration and how the app handles web content, while applying noopener and governing new windows is yours to implement.

What to take away

Reverse tabnabbing lets a page opened via target="_blank" or window.open without noopener redirect the opener through window.opener, typically to a phishing site, while the user looks at the new page.
It follows web content into mobile WebViews, where the protective browser defaults may not apply, so it is worth handling in any app that renders web content opening links.
Prevent it by adding rel="noopener noreferrer" to such links, using noopener with window.open, controlling how the WebView handles new windows, and restricting untrusted content.
Use a pre-submission scan such as PTKD.com to surface your WebView configuration and web-content handling, and enforce noopener in your app's web content.