GuiGui's Show

Résumé : si t'es adminsys ou développeur d'un site web qui utilise des ressources externes (CSS, police de caractères, JS, frames vidéo / tweet / carte géographique, CAPTCHA etc.) à gogo hébergées chez les géants du net (Google, CloudFlare, Adobe, BootstrapCDN, jsDelivr, Youtube/Vimeo/Dailymotion) que tu ne peux pas virer, ajoute au moins l'entête HTTP « Referrer-Policy "no-referrer" » côté serveur ou dans le code. Cela limite un peu le flicage des visiteurs de ton site web par les quelques géants économiques sus-cités, y compris celui des visiteurs sans connaissances techniques (pour les autres, il y a Smart Referer pour Firefox). Ces acteurs ne seront plus en mesure de suivre tes visiteurs sur ton site (quelles pages il a consulté) ni entre les sites (leur position hégémonique le leur permet). Ça complète les récents blocages par défaut des traqueurs et des cookies tiers par les navigateurs web. Les sites web internes (intranet, webmail, messagerie web, lecteur de flux RSS, etc.) restent d'excellents clients de « Referrer-Policy "no-referrer" » afin d'éviter de dévoiler leur existence au monde.

Il y a quelques mois, j'évoquais l'entête HTTP nommé « Referrer-Policy ». Je n'en avais pas capté tout le potentiel, donc revenons dessus.

Quand il suit un lien (intra-site ou inter-sites web), un navigateur web indique, à la page web de destination, de quelle page de quel site web il vient. C'est l'entête HTTP « Referer ». Exemple : « Referer: https://www.mediapart.fr/journal/economie/130218/les-milliardaires-de-la-presse-gaves-d-aides-publiques-et-privees » signifie que le navigateur vient de cet article précis de ce journal précis et que l'utilisateur a cliqué sur un lien situé dans cette page.

Cet entête est journalisé côté serveur web. C'est même la configuration par défaut du serveur web le plus utilisé, Apache httpd. Cela crée donc un journal qui associe une date, un Referer, une page web demandée et d'autres infos à une adresse IP. Exemple : « 2001:db8::1 - - [07/Apr/2020:16:09:03 +0200] "GET /?rc4hwA HTTP/1.1" "https://www.google.fr/" "Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0" ». Le 07 avril 2020 à 16 h 09 m 43 s, l'adresse IP « 2001:db8::1 », utilisant un navigateur web Mozilla Firefox version 68 sur un système GNU/Linux, en provenance de Google Search, a demandé à consulter ma page web « /?rc4hwA ». Cette personne est donc arrivée sur mon site web après une recherche sur Google.

Ce Referer est également transmis à chaque fois qu'un élément constitutif d'une page web (image, police de caractère, contenu encapsulé comme une vidéo, CSS, Javascript, etc.) est récupéré. Or, sur tout site web moderne, le CSS est récupéré depuis BootstrapCDN, la police de caractère depuis Google, le Javascript depuis CloudFlare, la vidéo encapsulée depuis Google Youtube, le CAPTCHA depuis Google, etc. et les statistiques sont envoyées à Google Analytics. Les noms sont des exemples parmi d'autres. Je le déplore, ce n'est pas le web authentique, mais c'est un fait.

Cela signifie qu'une poignée d'acteurs économiques (Google, CloudFlare, BootstrapCDN, jsDelivr, etc.) consignent une association adresses IP + Referer. Comme tout le monde utilise leurs services, ils peuvent suivre notre navigation au sein d'un site web et entre les sites web. Untel a lu tels et tels articles dans le Figaro (il y a l'URL complète dans le Referer, voir ci-dessus), puis il a été sur tel site de rencontre et il y a regardé tels et tels profils (URL complète, toujours ;) ) puis il a consulté tel autre site web. Tout ce flicage se fait sans cookies (d'ailleurs, ces acteurs n'en déposent généralement pas quand on récupère CSS, police, etc.). Je ne dis pas que ces acteurs vont utiliser ces informations à mauvais escient, mais ils les collectent. Or, une collecte sans utilisation aujourd'hui peut conduire à une compromission de la vie privée demain (décision de la Cour de Justice de l'Union Européenne Digital Rights Ireland de 2014). C'est l'évidence même, comme une sextape sans utilisation malveillante aujourd'hui laisse la porte ouverte à un chantage demain.

Si tu veux pinailler sur la technique (sinon saute au prochain paragraphe), je dois écrire qu'il y a des exceptions au point précédent.

• Par défaut avec Mozilla Firefox, le Referer n'est pas envoyé quand on passe d'un site web HTTPS (chiffrement) à un site web HTTP (pas de chiffrement). C'est la politique dite « no-referrer-when-downgrade ». Ce comportement par défaut est modifiable dans la configuration avancée de Firefox mais le faire rend la navigation web parfois invivable ;
  
  
• De même, si une police de caractères est chargée depuis un CSS, alors c'est l'URL du CSS qui est renseignée comme Referer. Si le CSS est externalisé, chez BootstrapCDN par exemple, alors c'est BootstrapCDN qui est consigné dans le Referer, pas le site web d'origine. D'autres ressources peuvent être dans cette situation.

Pour se prémunir de ce flicage, il est possible d'installer l'extension Firefox Smart Referer. Elle permet de contrôler la diffusion du Referer, y compris de l'autoriser automatiquement sur les sites web qui ne fonctionnent pas sans lui (cela fonctionne avec une liste blanche). Par défaut (si le site web n'est pas dans une liste blanche), cette extension envoie l'URL de la destination comme Referer.

Seule une minorité de personnes installera cette extension (ou équivalent) par manque de connaissances. Or, la vie privée est pour tout le monde. L'éditeur d'un site web (ou ses sous-traitants développeurs et hébergeurs) peut positionner l'entête « Referrer-Policy » sur son site afin d'indiquer au navigateur web de ses visiteurs de ne pas transmettre le Referer ou de le caviarder en fonction des situations. Cela peut se faire dans la configuration du serveur web, y compris celle déportée que constitue un fichier « htaccess », ou dans le code du site (PHP, XHTML, etc.).

Exemple Apache httpd (y compris .htaccess) :

Header set Referrer-Policy "same-origin"

Exemple nginx :

add_header Referrer-Policy "same-origin";

On peut aussi le définir dans le code du site web. Exemple en PHP :

header('Referrer-Policy: "same-origin"');

Ou dans une balise XHTML (méthode retenue par Google Search + valeur « origin » afin que les sites visités à partir de lui voient que les visites viennent de Google mais ne voient pas les mots-clés recherchés) :

<meta name="referrer" content="same-origin">

Dans ces exemples, j'interdis l'émission du Referer en dehors du même site web. Pour être exact, je l'interdis dès qu'un des membres du triptyque protocole+domaine+port diffère, donc les sous-domaines d'un site web seront considérés comme des sites web externes, donc le Referer ne sera pas transmis.

D'autres politiques sont possibles comme envoyer uniquement le domaine au lieu de l'URL complète (« origin ») comme le fait Google sur son moteur de recherche ou ne pas transmettre du tout le Referer (« no-referrer »).

La politique du Referer n'a pas d'impact sur les outils de statistiques (Google Analytics, Xiti, Matomo ‒ anciennement Piwik ‒, etc.).

• L'origine de la visite (moteur de recherche, site web, etc.) sera jamais perdue, même avec la valeur la plus stricte, « no-referrer ». C'est logique : la politique du site d'où l'on vient s'applique à la page web en cours, la politique de cette dernière s'applique aux éléments qui la constituent (images, CSS, etc.) et aux pages (internes et externes) sur lesquelles on ira par la suite en suivant un lien. Notons qu'avec « no-referrer », la requête HTTP récupérant le fichier JS qui constitue l'outil de statistiques (ga.js, matomo.js, etc.) ne contiendra pas de Referrer, mais le script sera autorisé à utiliser l'élement Javascript « document.referrer » afin de récupérer celui de la page web. Dit autrement : le Referer positionné (ou non) sur la requête de récupération de l'outil statistique a aucune importance ;
  
  
• La fonctionnalité « pages les plus lues du site web » ne se base pas non plus sur le Referer. J'ai testé avec Matomo (instance auto-hébergée sur un sous-domaine, configuration par défaut, utilisation du traqueur Javascript).

Il faut quand même prêter attention aux très vieux sites web qui utilisent le Referer pour valider l'envoi de formulaires web ou autre. Ça fait 15 ans que les bonnes pratiques commandent de ne pas faire ça car ça n'apporte pas de sécurité, mais bon… Au quotidien, au niveau mondial, la liste des sites qui cessent de fonctionner en l'absence de Referer est très maigre, la liste blanche de Smart referer en est l'illustration. Mais ça peut être plus touchy sur des sites web internes / maison.

Évidemment, il y a des cas où cet entête ne fonctionne pas :

• D'autres entêtes HTTP communiquent l'URL plus ou moins complète du site web sur lequel nous naviguons. C'est le cas de l'entête « Origin » positionnées dans les requêtes AJAX (XMLHttpRequest) ou dans les requêtes de récupération d'une police de caractères depuis un fichier CSS (« @font-face ») ou dans d'autres cas encore. Ces fuites ne peuvent être évitées (pas même avec l'extension Smart Referer) car elles participent à la politique de sécurité dite CORS ;
  
  
• Les contenus encapsulés, comme une vidéo Youtube, sont autonomes, indépendants de la page web qui les incruste, donc ils appliquent leur propre politique de transmission du Referer ou celle par défaut du navigateur web (pour Firefox : transmettre sauf si passage de HTTPS à HTTP).

Le mieux est donc d'internaliser tous les éléments qui composent ton site web, CSS, police de caractères, jquery, outil de statistiques (Matomo ‒ anciennement Piwik ‒ et son guide de configuration par la CNIL sont là pour ça, etc.) et de préférer un lien vers un contenu externe (vidéo, carte géographique, Twitter, etc.) à son inclusion sur la page sous forme de widget / gadget. Au moins, le visiteur ne se fait pas renifler le cul sans le savoir par les mêmes acteurs hégémoniques, et, s'il suit un lien, il le fait en connaissance de cause, en acceptant la politique du site web pointé, il a le choix.

L'internalisation à d'autres avantages :

• Pas de dépendances à des acteurs économiques avec lesquels tu n'as pas de contrat donc aucune assurance de pérennité ni garantie d'absence de panne (Google a déjà été en panne, CloudFlare aussi). C'est dommage de ne plus avoir de mise en forme sur son site car un acteur toussote à l'autre bout d'Internet… ;
  
  
• Site web moins long à charger car moins de requêtes DNS+TLS+HTTP à effectuer.

Comme un décideur ou un développeur aura toujours une bonne excuse pour ne pas internaliser (« pas la priorité », « pas le temps », « le gain est faible », « je ne connais pas assez mon framework pour savoir si c'est possible »), l'entête Referrer-Policy est un premier pas pour nettoyer un site web et protéger un poil plus la vie privée des visiteurs. Je recommande la valeur « no-referrer ».

Je trouve qu'une politique du Referer ferme complète assez bien le récent blocage par défaut des traqueurs tiers par Mozilla Firefox et le très récent blocage par défaut de tout cookie tiers par Apple Safari. Les principaux traqueurs et les cookies tiers éliminés sans action de l'utilisateur, il reste le Referer, les traqueurs déguisés et les contenus externalisés. Avec une politique du Referer ferme, il reste les traqueurs masqués, dont uBlock Origin sait s'occuper depuis peu (mets-le à jour), et les contenus externalisés à outrance. On progresse. La vie privée progresse.

Ce que j'ai écrit dans mon dernier shaarli sur Referrer-Policy reste valable : je recommande vivement son usage sur des sites web internes : intranet, webmail, messagerie web comme Mattermost (dès que quelqu'un envoie une image, vidéo, URL, le contenu est récupéré automatiquement et affiché), lecteur de flux RSS, etc. Cela évite les fuites, cela évite d'informer l'extérieur de l'existence de ressources internes (je simplifie, d'autres fuites restent possibles, au niveau DNS, par exemple, mais, pour en """"bénéficier"""", il faut être dans un cercle relativement fermé).