Sécurité et performance de vos liens target=_blank avec rel=noopener

Il y a un an presque jour pour jour, nous annoncions une mise à jour du référentiel de bonnes pratiques de notre service d’analyse de sites web. Cette mise à jour intégrait un point de contrôle sur les attributs des liens hypertextes visant à provoquer l’ouverture du lien dans une nouvelle fenêtre ou onglet (target=”_blank”).

La dernière version de Firefox a désormais rejoint Google Chrome en supportant l’attribut rel=”noopener”, l’une des solutions que nous fournissions. Prenons donc le temps de revenir sur cette recommandation, que nous avons apportée pour des objectifs de sécurité mais qui répond également à des enjeux de performance.

L’attribut target=_blank sur vos liens, un problème de sécurité

Mathias Bynens l’a illustré de manière très explicite : l’utilisation d’un attribut target=_blank sur un lien hypertexte permet à la page web ouverte de déclencher un changement de page dans la fenêtre d’origine. Son article propose également des pages de démonstration si vous souhaitez visualiser le problème.

En bref : si vous autorisez des internautes à publier des liens sur votre site et que ces derniers utilisent l’attribut target=_blank, vous vous exposez à ce qu’un attaquant redirige l’internaute vers une autre page. Non pas dans l’onglet qui a été ouvert en cliquant sur le lien, mais dans l’onglet d’origine (votre site). Et ce sans aucun avertissement. Une méthode qui peut donc s’avérer très efficace pour du phishing par exemple.

Par défaut, une page a en effet accès à l’éventuelle page appelante par l’attribut window.opener, et elle peut en modifier l’attribut location, même si les 2 pages ne sont pas sur le même domaine.

L’attribut target=_blank sur vos liens, un problème de performance ?

Comme l’a montré Jake Archibald, les liens ouverts dans de nouvelles fenêtres sont aussi impactés en matière de performance. Ici encore, vous pourrez trouver dans l’article une page de démonstration.
Le problème est le suivant : sur la plupart des navigateurs, lorsque vous ouvrez ainsi une nouvelle fenêtre ou un nouvel onglet depuis une page existante, les 2 fenêtres se retrouvent à partager le même processus système. L’utilisation commune de ce processus peut donc conduire à des interférences entre les 2, des traitements intensifs sur une fenêtre inactive pouvant impacter la fluidité de la page utilisée par l’internaute.

Résoudre les problèmes avec rel=noopener

Rappelons tout d’abord que la plus simple des solutions est de ne pas utiliser target=_blank, qui peut aller à l’encontre des bonnes pratiques d’accessibilité si l’utilisateur n’est pas informé de ce comportement (comme le rappelle le référentiel Opquast).

Si vous devez utiliser cet attribut, vous devriez alors l’accompagner d’un autre : rel=noopener. Cet attribut rendra nulle la valeur de window.opener (interdisant donc tout changement d’URL sur la page appelante).

Compatibilité des navigateurs avec rel=noopener

Malgré le support récent (début mars 2017) de cette fonction par Firefox comme annoncé en introduction, la compatibilité des navigateurs avec rel=noopener est encore trop limitée pour considérer qu’il vous permettra de résoudre le problème de sécurité posé.

Vous pourrez alors vous tourner vers rel=noreferrer, largement supporté, qui aura le même effet. Mais comme son nom l’indique, il privera également le site de destination de la réception d’un en-tête HTTP Referer fournissant l’origine du trafic.

rel=noreferrer et rel=noopener sur tous vos liens ?

Si vous acceptez du contenu contributif pouvant inclure des liens (typiquement les commentaires sur les blogs), assurez-vous de ne pas utiliser de target=_blank ou de prendre les mesures nécessaires. Pour les liens externes dont vous avez la responsabilité, le risque de sécurité est fortement mitigé car son exploitation impliquerait que l’attaquant injecte du javascript sur une page ainsi liée. Enfin s’il s’agit de liens internes, le risque de sécurité ne se pose pas mais les enjeux de performance persistent.

Une solution plus globale devrait arriver avec la version 3 de Content Security Policy qui pourrait proposer une directive disown-opener, qui permettrait donc d’éviter de préciser un attribut sur chaque lien.

Pensez à tester régulièrement votre site avec Dareboost pour vérifier l’application de cette bonne pratique sur vos pages et bénéficier de tous nos autres points de contrôle qualité.