Is Using target="_blank" Hurting Your Website?

Is Using target="_blank" Hurting Your Website?

Learn About the Security and UX Dangers Behind This Simple Attribute

·

5 min read

Whether you went to a bootcamp or are a CS grad, HTML attributes were likely just a quick footnote in your coursework. And most of that time was probably spent talking about attributes for form elements. But what about the humble target attribute?

The default value for target is _self, which is the current browsing context. It is well known that setting target="_blank" opens the link in a new tab. Because target="_blank" is a change in default behavior many people argue heavily against using it. I am a cmd and click girl, so I prefer most links to be opened in a new tab. But taking away the option to open a link in the same tab just because I prefer it may frustrate some users. Let's talk about accessibility concerns, instances when it's okay to use _blank, and some security risks to avoid when you do so.

TLDR: Avoid target="_blank" unless you don't want a user to lose progress or you're linking to an external source in an article. If you use it, implement the accessible solution below and add rel="noopener noreferrer" to protect against malicious attacks.

Accessibility Concerns

Screen readers do not announce that a link will open in a new window when the behavior is not explicitly declared in the link text. According to PowerMapper, the link below would cause problems in 43 screen readers and browser combinations.

<a href="https://hashnode.com/" target="_blank">Example Link</a>

If you are going to use target="_blank", make sure to give the user some sort of indication of this behavior. A common way to do this is to include an SVG after the button text like in this example:

The SVG icon is fine for sighted users, but other users will still need an advanced warning when opening a new window. Some sites use a pop-up advisory or a hidden span, but I'm a fan of Scott Vinkle's approach.

Scott advises using the following HTML container in combination with aria-describedby. The hidden attribute is used to hide content both visually and from screen readers. According to MDN, this is an acceptable use of this attribute.

<div hidden>
  <span id="new-window-0">Opens in a new window</span>
  <span id="new-window-1">Opens an external site</span>
  <span id="new-window-2">Opens an external site in a new window</span>
</div>

This container will be referenced with the aria-describedby attribute in the link resulting in the screen reader announcing "My site - Opens in a new window". This solution is easy to implement and is a good solution for scenarios when you must use target="_blank". Make sure to read the full description on Scott's blog!

<a href="https://mysite.com" target="_blank" rel="noopener" aria-describedby="new-window-0" >
 My site 
 <svg role="presentation" aria-hidden="true" focusable="false" ...>
    <path>
      <!-- ... -->
    </path>
  </svg>
</a>

Now that you're aware of an accessible solution for _blank scenarios, when should you actually use it?

  • If the user is filling out a form or working on something, clicking a link could cause them to lose their progress. You should have some kind of safety net in place for accidental clicks, such as prompting the user to save before leaving, but target="_blank" may be necessary for some links.

  • If a user is going through the checkout process, clicking on a link like "my rewards balance" shouldn't take the user away from the payment screen. You can keep links in the footer as _self since this behavior should be expected, but most other links on a checkout page should be _blank.

  • If you've clicked on any of the external resources I've linked in this article, you've probably noticed that Hashnode has set all of them to target="_blank". When I'm reading an article, I will always cmd and click a link for more information because I want to come back to where I left off in the article. Most users don't want to go down a rabbit hole in the new site and not be able to come back to the original article. I think setting external resources to target="_blank" is okay.

If one of these use cases applies to you, then feel free to use _blank! But before you do, there are some security risks associated with the value that can be easily avoided.

Security Risks Associated With target="_blank"

Whenever you use target="_blank" the linked page gains partial access to the linking page via the window.opener object. By either using open() or clicking on a link with the target attribute, the opener property returns a reference to window A that opens window B.

Window B can then change the window.opener.location value to a phishing page. This action will change the address bar of the tab. Some users may not notice the change and will enter their sensitive information. Google is aware of this behavior and calls this kind of attack tabnabbing. They believe that tabnabbing, unfortunately, can't be mitigated by any single website because the attacks are inherent to the current design of the browsers. As web users, we need to always be aware of the URL bar, but there is an easy way to protect your site users.

For all outgoing links add rel="noopener noreferrer.

noopener prevents the above scenario by not setting the window.opener property on the opened window. Instead of the URL of your site, window.opener will just return null. In newer browsers this is the default behavior when you set target="_blank", but it's always a good idea to add noopener if you need to support legacy browsers.

norefferer instructs the browser to omit the Referer header when navigating to a new page. In terms of analytics, if someone clicks on a link to your site that has noreferrer, Google Analytics will not show who referred that link. It will report it as direct traffic instead.

✨Next time that you are typing out an <a> element, ask yourself if it is really necessary for it to open the link in a new tab. If so, be sure to make your link safe from phishing attacks and accessible to screen readers.