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.
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 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.
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.
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.
Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.
Stay up to date. Get informed of the latest happenings in the development world.
Another solid bundle for developers!
Start at $1. Pay what you want and get up to 18 Ruby books for your collection.
If you buy something through a link, we may earn a commission