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?
- Hacker can redirect your domain.
- CSRF can be performed.
- 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 👇
Top comments (19)
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!
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.
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.
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".
@deathshadow60 No hard feelings, Have you ever tried to exploit this way?
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.
It's been plugged, but realize there are people who haven't updated their browsers since years ago.
"what" has been fixed exactly?
Isn't this still a potential attack vector?
thecodest.co/blog/web-app-security...
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:
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:
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.
@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/ 😃
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.
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.
yeah that makes sense! Thanks for sharing background.
Idk but, why is the comment section is a better article itself?
I guess there an update because i'm facing same problem in escribe
Right 👍🏼
Thanks for sharing
thanks for sharing
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 😂😂