Qu'est-ce que Referrer-Policy ?

L'en-tête HTTP Referrer-Policy contrôle la quantité d'informations sur la page d'origine incluse dans l'en-tête de requête Referer lorsqu'un utilisateur navigue de votre site vers un autre, ou lorsque votre page charge des ressources depuis des sources externes. Chaque fois que quelqu'un clique sur un lien, chaque fois qu'une image est chargée depuis un CDN, chaque fois qu'un script d'analyse se déclenche, le navigateur envoie potentiellement l'URL de la page courante au serveur de destination. Referrer-Policy vous permet de décider quelle part de cette URL partager.

(Une remarque rapide sur l'orthographe : l'en-tête HTTP s'écrit "Referer" avec un seul "r" en raison d'une faute d'orthographe dans la spécification HTTP originale du début des années 1990. L'en-tête de politique utilise l'orthographe correcte "Referrer" avec deux r. Les deux orthographes sont intentionnelles.)

Ce que contient l'en-tête Referer et quand il est envoyé

Par défaut (sans Referrer-Policy), le navigateur envoie l'URL complète de la page courante comme en-tête Referer avec la plupart des requêtes sortantes. Cela inclut :

• Navigation : lorsqu'un utilisateur clique sur un lien vers un autre site web, la destination reçoit l'URL complète de la page d'où il provient.
• Requêtes de sous-ressources : lorsque votre page charge des images, scripts, feuilles de style ou polices depuis des domaines externes, chaque requête inclut l'en-tête Referer.
• Soumissions de formulaires : lorsqu'un formulaire envoie des données à une URL externe, l'en-tête Referer est inclus.
• Requêtes AJAX et Fetch : les appels d'API vers des services externes incluent également l'en-tête Referer par défaut.

Supposons qu'un visiteur se trouve sur cette URL de votre site WordPress :

https://votresite.com/members/dashboard?session=abc123&plan=premium

Si cette page contient une image intégrée provenant d'un fournisseur d'analyses externe ou d'un réseau publicitaire, le serveur de ce fournisseur reçoit l'URL complète dans l'en-tête Referer, y compris les paramètres de requête contenant le jeton de session et les informations sur le forfait. C'est le problème de confidentialité que Referrer-Policy résout.

Toutes les valeurs Referrer-Policy expliquées

L'en-tête Referrer-Policy prend en charge huit valeurs distinctes. Chacune définit un niveau différent de partage d'informations :

• no-referrer : n'envoie jamais l'en-tête Referer. La destination ne reçoit aucune information sur la provenance de la requête. C'est l'option la plus privée, mais elle peut casser des fonctionnalités qui dépendent des données de référent (certaines protections CSRF, par exemple).
• no-referrer-when-downgrade : envoie l'URL complète, mais supprime le Referer lors d'une navigation de HTTPS vers HTTP (un "downgrade"). C'était la valeur par défaut des navigateurs pendant de nombreuses années. Elle protège contre la fuite d'URL en quittant un contexte sécurisé, mais partage tout en navigation HTTPS-vers-HTTPS.
• origin : n'envoie que l'origine (schéma, hôte et port) mais pas le chemin ni la chaîne de requête. Ainsi https://votresite.com/members/dashboard?session=abc123 devient simplement https://votresite.com/. La destination sait de quel site vient le visiteur, mais pas quelle page spécifique.
• origin-when-cross-origin : envoie l'URL complète pour les requêtes de même origine (liens internes à votre site) mais seulement l'origine pour les requêtes inter-origines. Cela donne à vos propres outils d'analyse internes des données de référent complètes tout en limitant ce que voient les sites externes.
• same-origin : envoie l'URL complète uniquement pour les requêtes de même origine. Pour les requêtes inter-origines, n'envoie aucun Referer. C'est très privé pour la navigation externe mais signifie que les services externes ne reçoivent aucune donnée de référent.
• strict-origin : envoie uniquement l'origine (comme la valeur origin), mais supprime entièrement le Referer lors des downgrades HTTPS-vers-HTTP. Combine la confidentialité d'origin avec la protection downgrade de no-referrer-when-downgrade.
• strict-origin-when-cross-origin : la valeur la plus couramment recommandée. Elle envoie l'URL complète pour les requêtes de même origine, seulement l'origine pour les requêtes inter-origines HTTPS-vers-HTTPS, et rien pour les downgrades HTTPS-vers-HTTP. C'est le meilleur équilibre entre confidentialité, sécurité et fonctionnalité. Les navigateurs modernes (Chrome 85+, Firefox 87+) l'ont adoptée comme valeur par défaut même en l'absence d'en-tête Referrer-Policy.
• unsafe-url : envoie toujours l'URL complète, quelle que soit la destination ou le contexte de sécurité. Elle est qualifiée d'"unsafe" pour une raison. Elle envoie les paramètres de requête, les chemins et tout le reste, même vers des destinations HTTP. Ne l'utilisez jamais sauf si vous avez un besoin très spécifique et comprenez les risques.

Implications pour la confidentialité de l'en-tête Referer

L'en-tête Referer est une préoccupation importante en matière de confidentialité que de nombreux propriétaires de sites négligent. Considérez quelles informations vos URL pourraient contenir :

• Requêtes de recherche : si votre site dispose d'une fonction de recherche, l'URL pourrait être /search?q=sujet+de+sante+sensible. Toute ressource externe chargée sur la page de résultats reçoit cette requête.
• Identifiants utilisateur : des URL comme /user/john-doe/profile ou /order/12345 divulguent des informations sur les utilisateurs et les commandes à des tiers externes.
• Jetons et données de session : certaines applications placent des jetons dans les URL pour les réinitialisations de mot de passe, les confirmations par e-mail ou les liens de partage. Ceux-ci pourraient fuiter via l'en-tête Referer.
• Structure d'URL interne : même la simple structure du chemin (/wp-admin/, /members-only/, /internal-dashboard/) révèle des informations sur l'architecture de votre site.

Chaque ressource tierce sur votre page est un destinataire potentiel de ces informations : Google Fonts, scripts d'analyse, boutons de réseaux sociaux, vidéos intégrées, réseaux publicitaires, bibliothèques hébergées sur CDN et images externes. Chacun reçoit l'en-tête Referer avec ses requêtes.

Pertinence pour le RGPD et la protection des données

Selon le RGPD et des réglementations de confidentialité similaires, les URL contenant des identifiants personnels ou des informations sensibles peuvent constituer des données personnelles. Si vos URL contiennent des noms d'utilisateur, des adresses e-mail ou d'autres informations identifiantes, partager ces URL via l'en-tête Referer avec des tiers pourrait poser un problème de protection des données.

Définir une Referrer-Policy est une mesure technique simple qui réduit le partage inutile de données avec des tiers. Bien qu'elle ne soit pas explicitement requise par le RGPD, elle s'aligne sur les principes de minimisation des données (Article 5(1)(c)) et de protection de la vie privée dès la conception (Article 25). Si votre délégué à la protection des données ou un audit de confidentialité demande quelles mesures techniques vous avez mises en place pour limiter les fuites de données, une Referrer-Policy correcte est un élément concret que vous pouvez citer.

Comportement par défaut de WordPress et extensions courantes

Le cœur de WordPress ne définit pas d'en-tête Referrer-Policy par défaut. Cela signifie que votre site dépend de la valeur par défaut intégrée du navigateur. Pour les navigateurs modernes, cette valeur par défaut est strict-origin-when-cross-origin, ce qui est en réalité une politique raisonnable. Cependant, il y a quelques points à noter :

• Les navigateurs plus anciens peuvent encore utiliser par défaut no-referrer-when-downgrade, qui envoie l'URL complète sur toutes les requêtes HTTPS-vers-HTTPS.
• Définir explicitement l'en-tête est mieux que de s'appuyer sur les valeurs par défaut du navigateur, car cela communique clairement votre intention et couvre toutes les versions de navigateurs.
• Certaines extensions de sécurité WordPress (comme Sucuri ou iThemes Security) incluent une option Referrer-Policy dans leurs paramètres de durcissement.
• WordPress 4.7.4 a introduit des améliorations de la fonction wp_get_referer(), mais il s'agit d'une fonction côté serveur qui lit l'en-tête Referer pour la protection CSRF. Elle n'est pas liée à l'en-tête de réponse Referrer-Policy.

Impact sur les analyses du site

Votre choix de Referrer-Policy affecte directement les données de référent que reçoivent vos outils d'analyse, et celles que les autres sites reçoivent sur le trafic provenant de votre site :

• Vos propres analyses : si vous utilisez Google Analytics, Matomo ou un outil similaire avec un script de suivi sur votre site, les requêtes de même origine incluront toujours le référent complet quelle que soit la politique (la plupart des politiques ne restreignent que les référents inter-origines). Vos données d'analyse sur site ne sont donc pas affectées par la plupart des valeurs de politique.
• Suivi du trafic entrant : la Referrer-Policy que vous définissez affecte ce que les autres sites voient lorsque vos visiteurs viennent de votre site. Elle n'affecte pas ce que vous voyez sur le trafic arrivant sur votre site (cela dépend de la politique du site référent).
• Suivi des affiliés et partenaires : si vous gérez un programme d'affiliation ou devez suivre les clics sortants, une politique très restrictive comme no-referrer cassera le suivi basé sur le référent. La valeur recommandée strict-origin-when-cross-origin envoie l'origine (domaine) aux partenaires, ce qui est généralement suffisant pour l'attribution.

Définir Referrer-Policy pour WordPress

La valeur recommandée pour la plupart des sites WordPress est strict-origin-when-cross-origin :

Referrer-Policy: strict-origin-when-cross-origin

Pour la définir dans Apache :

Header always set Referrer-Policy "strict-origin-when-cross-origin"

Dans Nginx :

add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Via PHP :

add_action('send_headers', function() {
    header('Referrer-Policy: strict-origin-when-cross-origin');
});

Si votre site traite des données particulièrement sensibles (informations médicales, dossiers financiers, documents juridiques), vous pouvez envisager une politique plus stricte comme same-origin ou no-referrer. Sachez simplement que cela supprimera les informations de référent pour toutes les requêtes inter-origines, ce qui peut affecter les services externes qui en dépendent.

Ce que vérifie InspectWP

InspectWP vérifie si votre site WordPress envoie un en-tête Referrer-Policy et rapporte la valeur configurée. Si l'en-tête est absent, votre site dépend de la valeur par défaut du navigateur de chaque visiteur, qui varie selon les versions de navigateur. Définir explicitement une Referrer-Policy garantit un comportement cohérent et démontre que vous avez pris une décision délibérée sur la quantité d'informations d'URL que votre site partage avec des tiers. Pour la grande majorité des sites WordPress, strict-origin-when-cross-origin est la valeur recommandée.