About one year ago, we were announcing an update of the quality checkpoints of our website analysis service. This update was including a new best practice related to hypertext links opening in a new window or tab by using target="_blank" attribute.
Joining Google Chrome, the latest Firefox version now supports the rel="noopener" attribute, which was one of our advised solutions. The right time for us to have a look back on this recommendation we have brought not only for better security but also for web performance.
target="_blank" attribute on your links: a security issue
Mathias Bynens have demonstrated it very clearly: using a target="_blank" attribute on hypertext links allows the new opened web page to trigger redirect within the initial window. Example pages can be used on his post if you wish to see the described issue by yourself.
To sum things up, if you allow your visitors to post links on your website with target="_blank" attribute, you allow an attacker to redirect users clicking such a link to another web page… The issue is that the redirect concerns the initial tab (your web page) , not the newly opened window when clicking the link! And the redirect is done without any warning. It could be used as a very effective phishing method for example.
By default, a web page can actually access to the opener page through the window.opener attribute and modify its location attribute, even if the two web pages are from different domains.
target="_blank": a performance issue?
As Jake Archibald have demonstrated it, web pages opened in new windows/tabs are also impacted regarding their performance. Once again, a demo page can be tested in that post.
Here is the point: most of the web browsers will share a same thread between the two windows when opening a link with a target="_blank" attribute. As a consequence, that thread sharing may lead to some interferences: intensive process in an inactive window could then degrade the fluidity of the web page currently displayed by the visitor.
About the rel="noopener" solution
First of all, please remind that the most simple solution is to avoid using target="_blank", that may also be against accessibility best practices if the users are not previously informed about behavior to be expected when clicking the link.
Still, if you have to use this attribute, you should add another one : rel="noopener". This attribute will set the window.opener value to null (and so forbid any URL change on the referring page).
Despite the recent support of this feature by Firefox (early march 2017), the browsers support of rel=noopener is still too limited to consider it as a solution to the current security problem.
You should also consider using rel="noreferrer" – as this attribute is widely supported – and offer the same behavior than rel="noopener". Nevertheless, it will additionally prevent the target page to receive a HTTP Referrer header.
rel="noreferrer" and rel="noopener" on every links?
If you are allowing contributive content that may contain links (Blog comments typically), you should ensure not to use target="_blank" attribute or to take all the necessary measures. Considering the external links you are responsible for, the security risk is quite limited as the attacker would have to inject javascript in the linked web page. Finally, about internal links, the security risk does not exist… but the performance issue remains.
One more global and developer-friendly solution should be shipped with the 3rd version of Content Security Policy, that could propose a disown-opener directive, to avoid setting an attribute for every single link.
Keep in mind to test your website with Dareboost on a regular basis, in order to check if your web pages comply with this best practice and to benefit from all of our other quality checkpoints.