DEV Community

Cover image for target="_blank" is a security risk?
Hassan Tahir
Hassan Tahir

Posted on • Updated on

target="_blank" is a security risk?

As we all use target="_blank" to open the link into new tab of a window but everyone should know a risk inside it.

When we open a new tab link window.opener get triggered which made a limited access to the specific tab opened, for example; you can not go back in the previous page by clicking back button from your URL bar.

So what is the risk here?
when the new tab link open it can alter the Link page URL from window.opener.location.
If your external link is not trusty that may cause a real problem to your website.

What can happen?

  1. Hacker can redirect your domain.
  2. CSRF can be performed.
  3. XML entities can be altered.

How to prevent this?
Do not forget to add relation attribute in your link tag rel=noopener noreferrer

In a Nutshell <a href="https://thehassantahir.web.app" target="_blank" rel="noopener noreferrer">Thehassantahir</a>

Comment your views &
Follow me on Github & Twitter and Sponsor me on
πŸ‘‡
Patreon Image

Discussion (19)

Collapse
deathshadow60 profile image
deathshadow60 • Edited on

Honestly I've never heard of it being a security risk any more than a normal href. It's NO different than middle clicking or ctrl-click in terms of mechanism of action.

You don't really say HOW it's actually a security issue. Literally if it is, then the entire way I normally navigate index pages on websites would be since I middle click a lot. No, A LOT.

This claim makes zero sense. I'm going to have to test this, it should not be triggering any event that isn't triggered on normal navigation. If that's true, that's horrifyingly bad.

That said, there is a perfectly legitimate reason to not set target="_blank", and it's why it was invalid in 4 Strict. It's usability and accessibility garbage breaking normal forward/back navigation and removing user choice. The user wants it iin a new window, they can middle click, ctrl+click, etc, etc. Don't shove new windows down the user's gullet!

Collapse
lexlohr profile image
Alex Lohr

There are multiple valid reasons to open a link in a new tab, the most compelling one of them being that you are inside a web app and the user expect links to open in a new tab.

And no, a wish for user retention is not a valid reason.

Collapse
deathshadow60 profile image
deathshadow60 • Edited on

I could see that if the point is to open it in a browser when in a "native" app such as running under Electron. If it's web facing in the browser? Not so much.

The problem is far too many developers throw it at everything, just BEGGING to get their tuchas sued off for WCAG violations given the middle finger it is to users on screen readers, braille readers, etc, etc.

But then that's my bread and butter, helping website owners who are in court for accessibility failings under laws like the US ADA, UK EQA, etc, etc. Thus why 90% of my job is instructing client's development teams in ripping out every last dumbass HTML/CSS framework, shredding anything remotely resembling CSR unless it absolutely positively cannot be done without, and taking a sledgehammer to garbage like target="_blank", pixel metric fonts/layout, illegible colour contrasts, and endless idiotic "DIV soup".

Like the client (public utility) I just helped who had this issue, alongside a broken inaccessible train wreck of angular that made it impossible for around a quarter of clients to even pay their bills online. Said site now rewritten from using 2 megabytes of "JS for nothing" and broken HTML, to a site that doesn't even use JavaScript, has 1/8th the markup, and not an accessibility violation in sight. They were shoving new windows down the users gullet too, to the point that when (if) their idiotic CSR trash worked, just logging in to "pay your bill" opened four freaking tabs! ON THE SAME SITE!!!

That's some serious hurr durrz ermagahd aherpaderp right there.

Thread Thread
lexlohr profile image
Alex Lohr • Edited on

Newsflash: you can run most electron apps that don't require node APIs directly in the browser. You can even install these web apps locally on most modern operating systems. And it's totally ok not to open a link in the same window in which a chat or a WebRTC meeting is currently open.

Yes, I get your point that target _blank is overused, but that doesn't make its use generally invalid inside the browser window. The main difference is the developer asking if target _blank actually improves the user experience and only uses it if the answer is "absolutely yes".

Collapse
thehassantahir profile image
Hassan Tahir Author • Edited on

@deathshadow60 No hard feelings, Have you ever tried to exploit this way?

Collapse
deathshadow60 profile image
deathshadow60

As I said, "I'm going to have to test this" -- and I just did, and it doesn't do what's claimed in Vivaldi or Firefox. Did some research and this security hole was apparently plugged years ago.

Thread Thread
codingjlu profile image
codingjlu

It's been plugged, but realize there are people who haven't updated their browsers since years ago.

Thread Thread
ravavyr profile image
Ravavyr

"what" has been fixed exactly?
Isn't this still a potential attack vector?
thecodest.co/blog/web-app-security...

Thread Thread
deathshadow60 profile image
deathshadow60 • Edited on

In the case that article outlines, at least for me in FF, Vivaldi, and Chrome (Winblows 10 and Linsux) window.opener is NULL meaning that code doesn't work. Their codeSandbox example throwing the following error:

TypeError Cannot set properties of null (setting 'location') HTMLAnchorElement.link.onclick

window.opener is null, As such they're only infecting two things. And Jack left town.

Technically if you open with _blank anyways unless you set rel="opener", there shouldn't be window.opener available on the resulting page either nor should it impact http_referer. As per what MDN says on it:

developer.mozilla.org/en-US/docs/W...

and I quote:

Windows opened because of links with a target of _blank don't get an opener, unless explicitly requested with rel=opener.

They also suggest setting Cross-Origin-Opener-Policy to same-origin in your CSP, which is good advice if you really care about it and are using the middle finger to accessibility.

As such the only people likely to get infected by it are those who don't update their browsers, in which case there are hundreds if not thousands of vulnerabilities they're open to, and they get what's coming to them.

Collapse
phil_dev profile image
Phil Pickering

@deathshadow60 Yes, it was an issue (see background info here: medium.com/sedeo/how-to-fix-target...)

@thehassantahir You might not be aware that this issue has now been fixed in all modern browsers mathiasbynens.github.io/rel-noopener/ πŸ˜ƒ

Collapse
deathshadow60 profile image
deathshadow60

It being fixed in modern browsers is likely why I just tried it here in both Vivaldi and Firefox, and said event did NOT fire.

Collapse
ravavyr profile image
Ravavyr

Read it again, In Edge it's a feature request that's not yet been added. Other than that yes, it's been patched in the other browsers.

You can still be 100% safe by doing -- target="_blank" rel="noopener" -- yourself as that hardly takes any effort.

Collapse
thehassantahir profile image
Hassan Tahir Author

yeah that makes sense! Thanks for sharing background.

Collapse
permanar profile image
Richie Permana

Idk but, why is the comment section is a better article itself?

Collapse
yasirq_2007 profile image
Yasir Qureshi

I guess there an update because i'm facing same problem in escribe

Collapse
thehassantahir profile image
Hassan Tahir Author

Right πŸ‘πŸΌ

Collapse
stonec0der profile image
Cedric Megnie

Thanks for sharing

Collapse
davidbug profile image
davidildefonso

thanks for sharing

Collapse
mevaldovi profile image
Marie Valdovinos

if you add the attribute "rel= noopener noreferrer" I have heard that the "target=_blank" is not a security risk. Not sure how accurate but that is what Stack Overflow told me πŸ˜‚πŸ˜‚