Mettre en place l'en-tête Referrer-Policy pour sécuriser son site
Je me dois de continuer mon épopée sur l'amélioration de la sécurité de JusteGeek.fr et ma progression vers le A en ce qui concerne les mécanismes contenus dans les en-têtes de trame HTTP. Si vous avez manqué le début : tout à commencé lorsque j'ai découvert le site securityheaders.com qui permet d'analyser son site au regard des mécanismes de sécurité contenus dans les en-têtes HTTP. Ma première note obtenue sur ce site fut... un F ! Soit la pire note envisageable. Je me suis donc attelé durement à cette tâche afin d'améliorer cela et de vous faire profiter de cette expérience pour vous donner les clés pour faire de même sur votre site. À l'heure actuelle, j'ai donc activé les en-têtes HSTS, X-Frame-Options, X-Content-Type-Options et X-XSS-Protection... Tout ceci m'a permis d'obtenir un B (bien mieux qu'un F....) mais ce n'est pas terminé. Aujourd'hui je vous propose de découvrir l'en-tête Referrer-Policy.
Comment fonctionne l'en-tête Referrer-Policy
L'en-tête HTTP referrer est utilisée par les navigateurs Internet pour indiquer d'où vient la requête. Par exemple, si je clique sur un lien vers www.nilux.fr depuis le site JusteGeek.fr, l'en-tête referrer informera nilux.fr (le site de destination) que la requête provient du site justegeek.fr (le site source). Ce comportement, qui peut être considéré comme pratique, notamment pour générer des statistiques de trafic, peut aussi présenter des risques relatifs à la sécurité et à la confidentialité. C'est pourquoi le W3C recommande de mettre en place une politique de Referrer (la Referrer Policy) qui permettra d'avoir la main sur ce qui est ou non envoyé dans cet en-tête.
Il existe de nombreuses directive concernant la Referrer Policy. Je vais ici vous les énumérer, mais si vous souhaitez avoir plus de détails, je vous renvoie aux explications du W3C sur ce sujet.
Les différentes directives sont donc :
- no-referrer : aucune en-tête referrer n'est envoyée
- no-referrer-when-downgrade : l'en-tête referrer est envoyée si la sécurité de la destination est la même (de HTTPS vers HTTPS) et aucune en-tête referrer n'est envoyée si la destination est moins sécurisée (HTTP)
- same-origin : l'en-tête referrer est envoyée si l'URL a la même origine, mais aucune en-tête referrer n'est envoyée si la destination n'a pas la même origine
- origin : l'en-tête referrer est envoyée mais contient seulement l'origine (le domaine) et pas l'URL complète
- strict-origin : l'en-tête referrer contient l'origine uniquement (et pas l'URL complète) si la destination est aussi sécurisée (HTTPS vers HTTPS). Si la destination n'est pas sécurisée (HTTP) alors aucune en-tête referrer n'est envoyée
- origin-when-cross-origin : l'en-tête referrer contient l'URL complète si la destination a la même origine et contient uniquement l'origine pour les autres cas
- strict-origin-when-cross-origin : l'en-tête referrer contient l'URL complète si la destination a la même origine et contient uniquement l'origine si la destination est aussi sécurisée (HTTPS vers HTTPS). Si la destination n'est pas sécurisée (HTTP) alors aucune en-tête referrer n'est envoyée
- unsafe-url : l'en-tête referrer contient l'URL complète dans tous les cas (non recommandé)
Pour ma part, j'ai décidé de définir ma politique sur "strict-origin-when-cross-origin".
Implémenter l'en-tête Referrer-Policy sur son site web
Bon maintenant que l'on en sait un peu plus sur l'en-tête Referrer Policy, il est temps de l'implémenter sur notre site Internet. Là encore, on peut implémenter cette directive directement dans la configuration du serveur web, ou bien uniquement sur un site en question, via le fichier htaccess ou la configuration du vhost. Pour ma part, j'ai décidé de le faire au niveau du serveur web, mais je vais vous donner les trois méthodes...
Définir l'en-tête Referrer-Policy dans la configuration d'Apache
Pour définir la Referrer-Policy dans la configuration d'Apache, il suffit d'éditer le fichier /etc/apache2/conf-available/security.conf et d'y ajouter la ligne suivante :
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Définir l'en-tête Referrer-Policy via le fichier .htaccess
Pour définir la Referrer-Policy via le fichier .htaccess il suffit de modifier la section mod_headers.c comme ceci :
<IfModule headers_module.c>
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>
Définir l'en-tête Referrer-Policy via la configuration du vhost
Pour définir la Referrer-Policy via la configuration du vhost, il convient d'ajouter les lignes suivantes, par exemple, juste avant la balise </VirtualHost>
<IfModule headers_module>
Header always set Referrer-Policy "strict-origin-when-cross-origin"
</IfModule>
Ensuite, quelle que soit la méthode que vous avez utilisée, un petit redémarrage du serveur web est nécessaire pour que cela soit pris en compte :
systemctl restart apache2
Conclusion
Et voilà ! Le mécanisme de Referrer-Policy est maintenant en place sur mon serveur web. Un nouveau check du site sur SecurityHeaders et hop, JusteGeek.fr obtient désormais la note A ! Cool !
Mais je ne vais pas m'arrêter là, puisque je vais viser le A+. Mais là, cela risque d'être un peu plus compliqué puisque les 2 mécanismes que je n'ai pas encore implémentés sont sans doute les plus compliqués à mettre en oeuvre... Mais je le ferai ! Promis !
Et si vous n'avez pas encore lu mes autres tutoriels pour arriver jusqu'au B, ils sont ici :
- Activer l'en-tête HSTS sur son serveur web
- Protéger son site web avec l'en-tête X-Frame-Options
- Protéger un peu plus son site web avec la balise X-Content-Type-Options
- Protéger votre site des attaques XSS avec l'en-tête X-XSS-Protection
Partager la publication "Mettre en place l'en-tête Referrer-Policy pour sécuriser son site"
Merci pour ces guides ! Je ne connaissais pas ces mesures, et mon site avait un petit "D". En suivant tes derniers tutos me voilà en "A" 😀
Le A+ sera peut être un peu plus compliqué à avoir, avec les deux directives restantes, non ?
Salut Cédric,
Content que ça t'ai servi.
Effectivement les derniers mécanismes sont pour moi les plus compliqués à implémenter. Mais je ne vais pas m'arrêter en si bon chemin. En revanche cela va peut être me prendre un peu de temps pour faire mes tests et implémenter proprement ces mécanismes...
++
bonjour,
Un grand merci, pour ces optimisations,
J'ai hâte de voir la suite car effectivement l'ajout de CSP n'est pas chose facile, je me demande même si cela est possible sur un e-commerce.
Salut SandStorm, Olivier,
Perso j'attends la suite parce que les deux derniers sont quasi impossible à mettre en place pour moi (sur un site WordPress)
Pardon les Features Policies sont simples à mettre en place (tu peux interdire le micro, la géolocalisation les notifications, la caméra) sur beaucoup de sites sans trop te poser de questions. Mais les CSP, mis à part avec un plugin WordPress (et en étant très vigilant) je ne vois pas…
Salut les gars !
Je vois que les CSP intéressent quand même les gens, il va vraiment falloir que je m'y mette 🙂