The biggest problem with using target=_blank

Before browsers had tabs, websites would often open new webpages in their own instances of the browser. You would eventually come to know these as pop-up windows. But you could also perform "pop-under"s in which new windows were opened underneath the current one. This was intrusive and companies often leveraged this feature to serve ads without users realizing it.

Then tabs made an appearance, and all of that window code pretty much became obsolete.

Nowadays, when web developers link to any outside URL from their own pages, they will do so with a target="_blank" attribute. The idea here being that their original page still remains open, so that their visitors don't completely leave their website. From a usability perspective, it totally makes sense.

But using target=_blank comes with several side effects that many web developers are usually unaware of that can cause vulnerabilities or even performance issues down the line. At least, on older browsers. More on that below.

The performance issue

When you open a link <a> using the target="_blank" attribute, the new page that loads may load under the same process as the current tab that triggered it.

That means that if the child page is running any form of high demand JavaScript the original page may feel the effects as well in terms of performance.

Like most people, I don't typically immediately close a tab once I am done skimming through it. It may remain open for a few hours or even a few days sometimes. If this window was opened through another link, then it is possible that my original page will suffer a performance hit until I close that child page. This can be more obvious if the child page is doing something like loading a heavy number of ads.

The same would be true for pages loaded through JavaScript using the window.open() method.

The window.opener issue

The biggest issue with using target="_blank" to open a webpage in a new tab, is in the fact that the browser may allow this new page access to the window.opener property.

The window.opener property essentially maintains a reference to the original page that opened the child page. Again, this can be any link opened using either the target="_blank" attribute or through the JavaScript method open(). Both will populate this property.

By default, if the origin of the secondary page is different than the original, then functionality with window.opener is limited. For example, the child page has no access to the variables or functions in the original page.

The child page does however have access to the window.opener.location property regardless of origin. And that is a big problem. Particularly if you don't have full control of the child page being opened because it is in a different domain. The issue can also occur on a website that allows for user input. An example would be in a comments form where users are allowed to enter any URL.

The child page could potentially alter the parent's window.location property and redirect to a different page altogether. The effect might be missed by the user and unknowingly enter information into an undesired location.

Using "noopener"

There is a way to explicitly tell the browser that the new page being open should not have a reference back to the caller page. And that is with the rel="noopener" attribute.

<a href='' target='_blank' rel='noopener'>Link goes here</a>

Using rel='noopener' will set the window.opener property on the child page to null.

You might also find it beneficial to also set the rel property to 'norefferer', which performs the exact action though it might work better on older browsers.

As of this writing though, modern browsers will implicitly add the 'noopener' property to links opened with a target='_blank' attribute, unless otherwise stated.

However, it's still beneficial to explicitly add the rel='noopener' attribute to outgoing links as not every user will be using the most up to date browser version.