Defaults.Exposed › Corrections › Referrer-Policy

Comment corriger Referrer-Policy

Une Referrer-Policy est une instruction d'une ligne que votre site transmet au navigateur de chaque visiteur, contrôlant quelle part de votre adresse web le suit lorsqu'il clique sur un lien vers un autre site. Sans elle, l'adresse complète de la page où il se trouvait — termes de recherche, numéros de compte, liens de réinitialisation, chemins de pages internes et tout le reste — est discrètement remise au site suivant où il atterrit, y compris annonceurs, régies d'analyse, et partout ailleurs où pointe un lien.

En clair, pour votre entreprise : Chaque fois qu'un visiteur clique sur un lien sortant, une publicité ou une ressource partagée, son navigateur peut remettre l'adresse complète de votre page à la destination — et si vos adresses contiennent des requêtes de recherche, des identifiants client, des numéros de commande ou des liens à usage unique, vous laissez fuir des données client vers des tiers que vous ne maîtrisez pas. C'est un problème de protection des données que les régulateurs prennent au sérieux, une promesse de confidentialité discrètement trahie, et une lacune notée que l'équipe de sécurité d'un client signalera lors de sa vérification préalable.

Ce que cela peut vous coûter

Un client remplit un formulaire ou lance une recherche, puis clique sur un lien sortant ou une publicité — et l'adresse de la page, avec ce qu'il a tapé, est remise directement à un annonceur ou à une régie d'analyse avec qui vous n'aviez jamais voulu la partager.
Les liens de réinitialisation de mot de passe et de confirmation de compte portent parfois un jeton secret dans l'adresse web ; sans cet en-tête, cliquer sur n'importe quel lien de cette page peut transmettre l'adresse entière — jeton compris — à un site extérieur.
Des chemins de pages internes privées (zones d'administration, pages réservées aux clients, paliers tarifaires, liens de documents) sont révélés à chaque tiers vers lequel vos visiteurs cliquent, livrant aux concurrents et aux curieux une carte de votre site qu'ils ne devraient jamais voir.
L'examen de sécurité d'un client ou un audit de confidentialité scanne votre site, ne voit aucune Referrer-Policy, et le consigne comme un manquement à la minimisation des données — le genre de constat qui bloque un contrat ou une certification.
Des données personnelles finissent entre les mains de sous-traitants avec qui vous n'avez aucun accord, transformant un oubli de cinq minutes en une violation de données à déclarer.

Pourquoi c'est important. Laissés à eux-mêmes, les navigateurs sont bavards : par défaut, ils indiquent au site suivant d'où vient le visiteur, souvent avec l'adresse complète de la page. Pour un site vitrine, cela peut être sans conséquence, mais dès l'instant où vos adresses contiennent quoi que ce soit de personnel — un terme de recherche, un identifiant de commande, un e-mail dans un lien, un chemin privé — ce comportement par défaut le laisse discrètement fuir vers l'extérieur. Une Referrer-Policy est le seul réglage qui dit aux navigateurs de cesser cette surdivulgation. C'est un contrôle noté sur votre bilan qui rapporte de vrais points, il correspond directement aux obligations de minimisation des données prévues par la loi sur la vie privée, et c'est l'un des en-têtes de sécurité standard que tout examen professionnel s'attend à trouver.

De quoi il s’agit, en clair

Chaque fois qu’un visiteur de votre site clique sur un lien vers un autre site — un lien sortant, une bannière publicitaire, un « partager ceci », même une police ou une image chargée d’ailleurs — son navigateur joint discrètement une note indiquant de quelle page de votre site il vient. Cette note s’appelle le référent (referrer).

Utilisé raisonnablement, le référent est inoffensif et même utile : c’est ainsi que les autres sites savent que le trafic vient de chez vous, et il alimente une bonne part des analyses honnêtes. Le piège est dans le comportement par défaut. Laissé sans contrôle, le navigateur ne dit pas seulement « ils viennent de votre-entreprise.com » — il livre souvent l’adresse complète de la page exacte, y compris tout ce qui suit le nom de domaine. Et les adresses web portent bien plus que les gens ne l’imaginent : termes de recherche tapés sur votre site, numéros de commande et de compte, chemin vers une page privée réservée aux membres, voire jetons secrets à usage unique dans les liens de réinitialisation de mot de passe et de confirmation.

Une Referrer-Policy est une instruction unique que votre site envoie au navigateur et qui indique quelle part de cette note il a le droit de partager. Vous pouvez lui demander de ne partager que votre nom de domaine, uniquement avec d’autres pages de votre propre site, ou rien du tout. Voyez-y la différence entre donner à un inconnu votre adresse postale complète avec votre emploi du temps quotidien, et simplement lui indiquer dans quelle ville vous habitez.

C’est l’un d’une petite famille d’« en-têtes de sécurité » — de courtes instructions que votre site donne au navigateur de chaque visiteur. Cela ne change ni l’apparence ni le fonctionnement de votre site. Cela empêche simplement le navigateur de trop en dire à votre place.

Ce que cela peut vous coûter

Voici des façons concrètes et quotidiennes dont une Referrer-Policy absente ou permissive mord de vraies entreprises. Aucune ne requiert un pirate — elles se produisent automatiquement, chaque jour, dans un usage normal.

La recherche divulguée. Un client cherche sur votre site quelque chose de sensible — un produit médical, un service lié à l’endettement, une comparaison de concurrents — et le terme de recherche atterrit dans l’adresse de la page. Il clique ensuite sur un lien sortant ou une publicité de cette page de résultats. L’annonceur reçoit alors votre adresse avec le terme de recherche dedans, apprenant exactement ce que votre client cherchait. Vous n’avez jamais accepté de partager cela, et vous ne pouvez pas le reprendre.
Le lien de réinitialisation exposé. Beaucoup de systèmes placent un jeton secret à usage unique dans l’adresse des pages de réinitialisation de mot de passe, de confirmation d’e-mail ou de « connexion magique ». Si cette page contient un lien sortant ou une ressource tierce, l’adresse complète — jeton compris — peut être remise à un site extérieur. Dans le pire des cas, cela donne à un tiers les clés d’un compte.
Le plan de site que vous offrez gratuitement. Vos chemins de pages internes révèlent souvent votre structure : /admin, /tarifs-entreprise, /clients/acme, /telechargements/rapport-prive. Sans cet en-tête, chaque site extérieur vers lequel vos visiteurs cliquent reçoit ces chemins. Les concurrents apprennent vos paliers tarifaires et vos gammes de produits ; les aspirateurs de contenu apprennent quelles pages cibler.
La relation de partage de données non voulue. La loi sur la vie privée attend de vous que vous sachiez à qui vont les données personnelles de vos clients et que vous ayez un accord en place. Laisser fuir des adresses de pages contenant des identifiants client ou des adresses e-mail vers des réseaux publicitaires et des régies d’analyse — sans accord et sans consentement — est exactement le genre de flux de données incontrôlé qui transforme un audit de routine en constat, et un constat en violation à déclarer.
L’affaire qui cale sur la vérification préalable. Quand l’équipe de sécurité d’un client plus important vous examine, l’absence d’en-têtes de sécurité standard est une case à cocher rapide et automatisée. Voir la Referrer-Policy absente leur indique que l’hygiène de confidentialité de base n’a jamais été mise en place — et cette impression teinte tout le reste de l’examen.

Ce que c’est vraiment

Par défaut, les navigateurs suivent un comportement à peu près équivalent à « strict-origin-when-cross-origin » sur les versions modernes — mais vous ne pouvez pas vous y fier, car les navigateurs plus anciens, les vues web intégrées et certaines configurations retombent encore sur une fuite plus large. Le seul moyen d’en être sûr est de définir la politique explicitement. Quand vous le faites, vous choisissez une règle dans une courte liste. Celles qui comptent :

no-referrer — ne rien partager. Le site suivant n’apprend rien sur l’origine du visiteur. Confidentialité maximale ; peut affaiblir vos analyses de référence.
same-origin — partager l’adresse complète uniquement lorsque le visiteur passe d’une page à l’autre de votre propre site ; ne rien partager avec les sites extérieurs.
strict-origin-when-cross-origin — la valeur par défaut recommandée. Au sein de votre propre site, le chemin complet est partagé ; vers les sites extérieurs, seul votre nom de domaine nu est partagé (et rien du tout en passant d’une page sécurisée à une page non sécurisée). Les tiers apprennent que le trafic vient de chez vous, mais jamais les détails privés après votre domaine.
origin — toujours partager uniquement votre nom de domaine, même au sein de votre propre site.

Et les deux valeurs à éviter, car le bilan les traite comme ne valant pas mieux qu’une absence d’en-tête :

unsafe-url — partager l’adresse complète avec tout le monde, toujours. Le pire des cas en un seul mot.
no-referrer-when-downgrade — l’ancienne valeur par défaut des navigateurs ; elle envoie encore l’adresse complète aux autres sites sécurisés, laissant fuir tout ce qui est décrit ci-dessus.

À quoi ressemble une situation « correcte » : un en-tête Referrer-Policy est présent et réglé sur une valeur restrictive — pour la plupart des entreprises, strict-origin-when-cross-origin. Cela maintient les analyses de référence en fonctionnement tout en garantissant que rien au-delà de votre nom de domaine n’atteigne jamais un site extérieur.

Comment corriger (gratuit, environ 5 minutes)

Transmettez cette section à votre informaticien, votre développeur web ou le support de votre hébergeur — le correctif est gratuit, c’est une ligne unique, et il ne cassera pas votre site. Aucun déploiement risqué ici : contrairement à certains réglages de sécurité, une Referrer-Policy raisonnable ne peut pas empêcher vos liens ou vos pages de fonctionner. Elle ne fait que réduire ce qui est partagé avec les autres sites.

L’objectif : définir un en-tête de réponse Referrer-Policy avec la valeur strict-origin-when-cross-origin (ou une valeur plus stricte si vous préférez partager encore moins).

Cloudflare (sans code — le plus simple si vous l’utilisez) : Tableau de bord → votre domaine → Rules → Transform Rules → Modify Response Header → Create rule → Set static → Nom de l’en-tête Referrer-Policy, valeur strict-origin-when-cross-origin → appliquer à toutes les requêtes entrantes → Deploy.

Google Workspace / Microsoft 365 : ces services gèrent votre messagerie, pas votre site, donc l’en-tête se règle là où votre site est réellement hébergé (votre hébergeur web, CDN ou serveur) — pas dans l’administration Workspace ou 365. Identifiez l’hébergeur et utilisez l’option correspondante ci-dessous.

Nginx :

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

Apache (dans la configuration du site ou .htaccess) :

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

IIS (web.config) :

<httpProtocol><customHeaders>
  <add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
</customHeaders></httpProtocol>

Node / Express :

app.use((req, res, next) => { res.setHeader('Referrer-Policy', 'strict-origin-when-cross-origin'); next(); });

WordPress / hébergeurs courants : la plupart des hébergements WordPress gérés et mutualisés permettent d’ajouter des en-têtes de réponse soit via une extension de sécurité, soit via un panneau « en-têtes » dans le panneau de contrôle de l’hébergement, soit via l’extrait .htaccess ci-dessus. Si vous êtes derrière Cloudflare, la méthode Cloudflare est la plus propre et s’applique partout d’un coup.

Après l’application : chargez votre site et relancez le contrôle, ou utilisez les outils de développement de votre navigateur (onglet Réseau → cliquez sur le document principal → En-têtes de réponse) pour confirmer que Referrer-Policy: strict-origin-when-cross-origin est présent.

Erreurs courantes

Définir une valeur permissive en croyant qu’elle compte. unsafe-url et no-referrer-when-downgrade laissent tous deux fuir l’adresse complète. Le bilan leur attribue zéro — identique à une absence d’en-tête. Si l’en-tête est présent mais que les points ne le sont pas, c’est presque toujours la raison.
Ne le définir que sur la page d’accueil. L’en-tête doit être envoyé sur chaque page, car les fuites se produisent sur les pages de résultats de recherche, de compte et de réinitialisation — pas sur la page d’accueil. Définissez-le au niveau du serveur, du CDN ou de Cloudflare pour qu’il s’applique automatiquement à tout le site.
Ne le définir que dans des balises HTML <meta>. Une balise <meta name="referrer"> fonctionne dans certains cas mais pas tous, et il est facile de la rendre incohérente d’une page à l’autre. Le définir comme un véritable en-tête de réponse (les méthodes ci-dessus) est l’approche fiable.
Laisser une couche en écraser une autre. Si votre serveur d’origine et votre CDN définissent tous deux l’en-tête avec des valeurs différentes, le résultat peut être imprévisible. Choisissez un seul endroit pour le gérer — généralement le CDN ou Cloudflare si vous en avez un — et gardez le reste cohérent.
Le traiter comme un substitut à l’absence de données dans les URL. L’en-tête limite les dégâts, mais l’habitude plus saine sur le long terme est de ne pas mettre de secrets et de données personnelles dans les adresses web dès le départ. Utilisez l’en-tête maintenant ; soulevez l’hygiène des URL avec votre développeur en suivi.

Une note rapide sur les en-têtes apparentés

La Referrer-Policy côtoie un petit ensemble d’autres en-têtes de sécurité web que nous vérifions — Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, et quelques en-têtes cross-origin avancés. Ils protègent des choses différentes, donc en avoir un ne couvre pas les autres. Si votre Referrer-Policy est absente, il vaut la peine de demander à celui qui la corrige de confirmer que les autres en-têtes standard sont en place en même temps, puisqu’ils se configurent généralement au même endroit et que cela ne coûte rien de plus.

En bref

La Referrer-Policy est le correctif de confidentialité le moins cher et le plus sûr de votre bilan : une ligne, environ cinq minutes, aucun risque de casser quoi que ce soit, et gratuit. Elle empêche les navigateurs de vos visiteurs de remettre discrètement les adresses privées de vos pages — et toutes les données personnelles qu’elles contiennent — à chaque site extérieur où ils cliquent. Réglez-la sur strict-origin-when-cross-origin, confirmez qu’elle est active sur chaque page, et la lacune de gravité moyenne et ses 15 points sont comblés.

FAQ

Je ne suis pas technique — est-ce vraiment quelque chose que je peux gérer ?

Oui, et c'est l'un des correctifs les plus simples de tout le bilan. C'est une ligne unique ajoutée par la personne qui gère votre site ou votre hébergement, et sur des services comme Cloudflare cela tient en deux clics sans aucun code. Transmettez-lui la section « Comment corriger » ci-dessous. C'est gratuit, cela prend environ cinq minutes, et contrairement à certains réglages de sécurité, cela ne casse rien sur votre site.

Que signifie « referrer » ici, au juste ?

Quand quelqu'un clique sur un lien de votre page vers un autre site, son navigateur joint une note indiquant de quelle page il vient — cette note s'appelle le référent (referrer). Elle est réellement utile pour des analyses honnêtes. Le problème, c'est que par défaut cette note inclut souvent l'adresse complète de votre page, pas seulement votre nom de domaine. Si cette adresse contient quoi que ce soit de privé, c'est partagé aussi. Une Referrer-Policy vous permet de réduire la note à votre seul domaine, ou de la désactiver, pour que rien de sensible ne fuie.

Cela vaut-il vraiment la peine si mon site ne gère pas de paiements ?

Presque certainement oui. Pas besoin d'un paiement en ligne pour avoir des informations privées dans vos adresses web — les barres de recherche, formulaires de contact, pages de compte, liens de documents et e-mails de réinitialisation de mot de passe mettent tous régulièrement des données dans la barre d'adresse. Et même sans aucune donnée personnelle, laisser fuir vos chemins de pages internes vers chaque site extérieur cliqué par vos visiteurs offre aux concurrents et aux aspirateurs de contenu une carte gratuite de votre site. Le correctif ne coûte rien et cinq minutes, donc peu de raisons de s'en passer.

Activer cela pourrait-il casser mon site ou mes analyses ?

Non. C'est l'un des en-têtes sûrs — il contrôle uniquement quelle part de l'adresse est partagée avec d'autres sites, pas si les liens fonctionnent. Le réglage recommandé envoie quand même votre nom de domaine aux sites extérieurs, donc les analyses de référence légitimes continuent de fonctionner ; il empêche seulement l'adresse privée complète de partir avec. Aucune période d'observation n'est nécessaire et rien à tester d'abord en préproduction.

Est-ce une question de loi sur la vie privée ou un simple confort ?

Cela peut être un véritable enjeu de conformité. Les règles de protection des données vous imposent de ne collecter et partager que le minimum de données personnelles nécessaires, et de savoir à qui vos données vont. Si vos adresses portent des identifiants personnels et que vous les laissez fuir vers des annonceurs ou des régies d'analyse sans accord en place, c'est un manquement à la minimisation des données que les auditeurs et régulateurs reconnaissent. Pour la plupart des entreprises, cet en-tête est un moyen concret et bon marché de combler cette lacune.

Cela affecte-t-il notre note, ou est-ce juste un conseil ?

Cela affecte votre note. Le contrôle Referrer-Policy est noté et vaut jusqu'à 15 points dans la catégorie Sécurité Web. Un en-tête manquant est marqué en gravité moyenne. Attention à un piège : régler l'en-tête sur une valeur permissive comme « unsafe-url » ou « no-referrer-when-downgrade » donne zéro point — comme si l'en-tête était absent — car ces valeurs laissent quand même fuir l'adresse complète. Pour gagner les points, il vous faut une valeur correctement restrictive comme « strict-origin-when-cross-origin ».