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.

JusteGeek.fr passé de C à B grâce à la mise en place de l'en-tête X-XSS-Protection

JusteGeek.fr passé de C à B grâce à la mise en place de l'en-tête X-XSS-Protection

 

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 !

JusteGeek.fr passé de B à A grâce à la mise en place de l'en-tête Referrer-Policy

JusteGeek.fr passé de B à A grâce à la mise en place de l'en-tête Referrer-Policy

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 :

 

Sandstorm

Ingénieur Systèmes passionné d'informatique et de High-Tech, Sandstorm a créé JusteGeek.fr en 2013. Il aime les geekeries en tout genre. "Si un produit s'allume c'est un bon point. S'il est connecté, c'est encore mieux !"

Vous aimerez aussi...

6 réponses

  1. Cédric dit :

    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" 😀 https://securityheaders.com/?q=https%3A%2F%2Fwww.maison-et-domotique.com&followRedirects=on
    Le A+ sera peut être un peu plus compliqué à avoir, avec les deux directives restantes, non ?

    • Sandstorm dit :

      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...
      ++

  2. olivier dit :

    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.

    • Nicolas Richard dit :

      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)

      • Nicolas Richard dit :

        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…

  3. Sandstorm dit :

    Salut les gars !
    Je vois que les CSP intéressent quand même les gens, il va vraiment falloir que je m'y mette 🙂

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.