Introduction

Le mécanisme dit de Referrer (qu’on peut traduire par « référent » en français) est selon Wikipedia :

Un référent, plus connu sous l’anglicisme Referer ou Referrer [1], est, dans le domaine des réseaux informatiques, une information transmise à un serveur HTTP lorsqu’un visiteur suit un lien pour accéder à l’une de ses ressources, lui indiquant l’URL de la page où se situe ce lien qu’il a suivi.

En pratique, quand un utilisateur navigue vers un autre site via un lien (ou si un site charge une ressource externe), le serveur informe le site de destination de l’origine de la requête en utilisant l’en-tête HTTP Referrer.

Si nous prenons l’exemple du logo d’Openweb, voici l’information de referrer envoyée :

Si nous ouvrons le lien précédent sur Wikipedia, voici l’information de referrer que l’on peut voir :

Cela peut être utile dans de nombreux cas (certains outils de statistiques se basent là-dessus, etc.), toutefois, cela peut aussi poser des problèmes de confidentialité et de sécurité. Ajoutons à cela que de nombreuses — et parfois insoupçonnées — APIs peuvent utiliser cette information... et parfois au désavantage des propriétaires de sites et/ou de leurs visiteurs.

Si ce mécanisme pouvait auparavant sembler être peu clair et peu paramétrable, une spécification relativement récente permet enfin d’en maitriser les comportements.

Referrer Policy

Son nom s’appelle très logiquement Referrer Policy, qu’on peut traduire par « Politique de referrers », ou « Politique de référents ».

Cette spécification est à l’instant de l’écriture de cet article une Candidate recommendation, c’est donc raisonnablement stabilisé et tout à fait utilisable en production.

À l’instar de Content Security Policy, vous pouvez donc avec Referrer Policy définir clairement votre politique en matière de referrers pour votre site… et la question est loin d’être aussi anodine qu’elle peut sembler l’être.

Principe et fonctionnement

Un en-tête HTTP est envoyé au navigateur contenant cette politique. En voici un exemple via PHP :

header("Referrer-Policy: <ici les valeurs possibles>");

Voici les valeurs possibles :

Referrer-Policy: no-referrer : aucun en-tête referrer n’est envoyé.

Referrer-Policy: no-referrer-when-downgrade (valeur par défaut) : le referrer est envoyé si la sécurité de la destination est à priori égale (HTTPS→HTTPS), mais n’est pas envoyé pour une destination moins sécurisée (HTTPS→HTTP).

Referrer-Policy: origin : seule l’origine du document sera envoyée dans tous les cas. L’adresse https://openweb.eu.org/articles/ enverra le referrer https://openweb.eu.org/.

Referrer-Policy: origin-when-cross-origin : envoie l’URL complète si la destination a la même origine, et seulement l’origine pour les autres cas.

Referrer-Policy: same-origin : le referrer sera envoyé pour les URLs avec la même origine, et aucun referrer ne sera envoyé dans les autres cas.

Referrer-Policy: strict-origin : le referrer ne contiendra que l’origine du document si la sécurité de la destination est à priori égale (HTTPS->HTTPS), rien ne sera envoyé pour une destination moins sécurisée (HTTPS→HTTP).

Referrer-Policy: strict-origin-when-cross-origin : quand la requête a la même origine, l’URL complète est envoyée en referrer. Dans le cas contraire : le referrer ne contiendra que l’origine du document si la sécurité de la destination est à priori égale (HTTPS→HTTPS), rien ne sera envoyé pour une destination moins sécurisée (HTTPS→HTTP).

Referrer-Policy: unsafe-url : l’URL complète est passée en referrer, quel que soit le cas.

Le réglage par défaut a longtemps été à l’origine d’un mythe : que le passage à HTTPS tuait en lui-même le mécanisme des referrers. Quand le HTTPS était beaucoup moins répandu qu’actuellement, avoir un site en HTTPS impliquait d’avoir majoritairement des liens vers des sites ne l’ayant pas (et donc aucun referrer envoyé vers une destination moins sécurisée). Le passage de Google à HTTPS il y a quelques années a fortement contribué à propager ce mythe. Néanmoins, HTTPS et referrers sont deux choses séparées, désolé de tuer cette légende urbaine ! :)

Implications et données sensibles

De prime abord, vous vous dites peut-être que votre site n’a rien à cacher :

• vous n’avez aucun problème à ce que les sites vers lesquels pointent vos liens soient au courant desdits liens ;
• ou les ressources que vous utilisez sur d’autres sites ne sont pas un secret d’état non plus…

Posons clairement la question : en êtes-vous bien sûr ?

Si certes, des liens publics ne sont pas des secrets d’état… peut-être votre site a une interface d’administration, et vous n’avez sûrement pas envie que l’adresse de cette dernière soit transmise en referrer.

Autre cas de figure : imaginons un intranet sur lequel vous pouvez partager des liens. Souhaitez-vous que l’adresse de ce dernier soit transmise vers l’extérieur ? Avec tout ce que cela peut révéler comme détails sur le fonctionnement de ce dernier ? Bien sûr que non !

D’autres APIs comme CSP peuvent également transmettre cette information. Voici un exemple d’informations qui peuvent arriver sur un report-uri :

{
 "csp-report": {
 "document-uri": "https://van11y.net/accessible-tab-panel/",
 "referrer": "https://plainjs.com/javascript/plugins/accessible-tabs-panel-system-163/",
 …
 }
}

Note : CSP étant assez verbeux de ce point de vue, ce genre d’information est fréquent.

Responsabilité en tant que concepteurs/possesseurs de sites

Vous avez plusieurs questions à vous poser en tant que concepteurs/responsables de sites à propos de votre politique de referrers.

Est-ce que l’adresse peut contenir des informations sensibles pour l’extérieur ?

S’il n’est pas souhaitable de communiquer certaines adresses vers l’extérieur, votre politique en matière de referrers doit le refléter. Et bien entendu, vous ne transmettez aucune information sensible en clair dans l’URL ?

Est-ce que l’adresse en elle-même est une information sensible ?

Si vous êtes sur un intranet ou une partie totalement privée de votre entreprise, c’est une information sensible que vous ne devez pas communiquer, a fortiori via referrer.

À titre d’exemple, si vous saviez le nombre surprenant d’intranets ou d’espaces privés qui partagent une page humoristique que j’ai créée il y a quelques années qui s’appelle « Est-ce qu’on met en production aujourd’hui ? »... je pense que les responsables sécurité de ces sites trouveraient moins drôle de savoir que cette information fuite, notamment en referrer dans des rapports générés par CSP que je reçois.

Beaucoup moins drôle comme exemple, imaginons un site d’entraide pour des femmes victimes de violences [2]. Imaginons donc une femme ainsi que l’état de choc dans laquelle elle peut se trouver après avoir été battue. Elle va donc laisser un message sur ce site, et peut-être parler du site personnel de son mari, pour dire que « c’était la première fois qu’il faisait ça », et « qu’il est gentil avec ses autres occupations ». Imaginons que ce dernier apprenne dans son outil de visites qu’un site de ce genre lui a envoyé des visites... que va-t-il penser suite à ce qu’il a fait à sa compagne ? Et que va-t-il faire ensuite ?

Autant le dire clairement : il est de la responsabilité du site de gérer et d’anticiper ce genre de risques. Certains sujets ne souffrent pas de traiter ces risques avec légèreté, et encore moins en tant que professionnels du métier.

Notes : des outils comme Mozilla Observatory suggèrent d’utiliser comme valeurs :

• no-referrer
• same-origin
• strict-origin
• strict-origin-when-cross-origin

Et ce, afin de ne pas divulguer d’informations sensibles.

Le W3c vous recommande de définir une politique de referrer.

Conclusion

Cette question des referrers dépasse de loin le simple cadre des statistiques des sites, et peut devenir un enjeu de sécurité ou de vie privée selon l’activité des sites.

Ce n’est bien évidemment pas un hasard si des outils comme Mozilla Observatory ou Security Headers invitent et recommandent d’utiliser cet en-tête de sécurité.

Maintenant que vous en connaissez les enjeux et le contexte, vous n’avez plus d’excuse pour ne pas le déployer en toute connaissance de cause à votre tour.

Références, compléments

• Referrer Policy (spécification W3c)
• Referrer-Policy (Mozilla Developer Network)
• Mozilla Observatory
• Security Headers
• Everything you could ever want to know (and more) about controlling the Referer header