Home / Knowledge hub / Tabnabbing
Knowledge hub
Tabnabbing
A link you opened silently changes the page that opened it, to a fake sign-in.
What it means
Tabnabbing happens when a page you link to gets a handle on the page that linked to it. In browsers, a new tab opened from a link can reach back through window.opener and change the address of the original tab.
The original tab is then swapped for a lookalike sign-in page while the user reads the new one. They come back, see a login prompt, assume their session timed out, and type their password into the attacker's page. The page they see looks right, and the address bar may even show a believable name.
Why it matters
The victim never leaves your domain in their own mind. The fake page appears in a tab they already trusted, which makes it a quiet route to phishing and stolen credentials, and it starts from a link your own product put in front of them.
Any place your app shows links to content someone else controls is exposed: user profiles, comments, support tickets, shared documents. A single link in a customer-written field can turn into an account takeover if the link is opened and the page behind it is hostile.
How it shows up
The pattern is a link with target="_blank" pointing at an address you do not control, or a script that calls window.open on one. Many current browsers treat target blank links as if they carried noopener, but not all, and script-opened windows still keep the opener.
The fix is cheap: add rel="noopener noreferrer" to outbound links and send a Cross-Origin-Opener-Policy header on pages that matter. Check user-generated links first, because that is where the hostile address comes from. Related ideas sit under the same-origin policy. Look at outbound links in templates first, then at any code that opens windows for the user.
Questions people ask
Tabnabbing, answered
Is tabnabbing the same as clickjacking?
No. Clickjacking hides your page under a frame so a click lands somewhere else. Tabnabbing leaves your page alone and rewrites a tab that was already open, using the link between the two windows.
Do modern browsers already stop it?
Partly. Current browsers imply noopener for links that open a new tab, so the classic case is much rarer than it was. Script-opened windows and older browsers can still expose the opener, so setting the attribute explicitly remains sensible.
What does rel=noopener actually do?
It tells the browser not to give the new page a reference to the page that opened it. The new tab gets a null window.opener, so it has nothing to redirect. Adding noreferrer also stops the address being sent as a referrer.
Where in my app should I look first?
Look wherever users can enter a link that other users will click: profiles, comments, tickets, chat messages, shared notes. Also check any admin screen that renders those links, since an operator clicking a hostile link is the higher-value target.
Does a content security policy prevent it?
Not by itself. A content security policy limits what your own pages load, not what a page you link to does to its opener. The opener policy header and the link attribute are the controls aimed at this.
Related
Terms that sit next to this one
Phishing
Persuading someone to hand over credentials by posing as a trusted sender.
Clickjacking
Tricking someone into clicking your button while it is hidden from them.
Same-origin policy
The browser rule that stops one site's scripts reading another site's data.
Cross-Origin-Opener-Policy
A header that isolates your page from windows opened by other sites.
Account takeover
An attacker ends up signed in as one of your real users.
Which of your links reach out?
Links that hand control to another page are checked as part of testing the running app, and each finding comes with the request and response that proved it. Ask us to run it on one of your applications.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.