Referrer-Policy, contrôler ce que le header Referer laisse fuiter

Referrer-Policy contrôle la part de votre URL qui fuit dans le header Referer lors des navigations. Valeurs, défauts et le choix sûr.

Chaque fois qu'un utilisateur suit un lien, et chaque fois qu'une page charge une ressource cross-origin (une image, un script, une iframe, un beacon d'analytics), le navigateur indique à la destination de quelle page venait la requête, dans le header Referer (une faute d'orthographe historique de « referrer » qui est restée). Cette adresse peut inclure l'origine, le chemin et la query string de la page courante, donc tout ce qui vit dans vos URL voyage avec : les liens de réinitialisation de mot de passe et autres liens de capacité, les requêtes de recherche, les données personnelles dans les chemins. Elle part vers les fournisseurs d'analytics, les CDN, les régies publicitaires et chaque site vers lequel vous liez.

Referrer-Policy est le header de réponse qui contrôle quelle part de cette URL sort, de l'adresse complète jusqu'à rien du tout. C'est la valeur à déployer sur chaque réponse HTML (voir la recommandation) :

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

Valeurs et ce que fait chacune

Dans le tableau, « URL complète » désigne l'origine plus le chemin plus la query string ; le navigateur n'envoie jamais le fragment (#...) ni les identifiants embarqués, quelle que soit la politique. « Downgrade » désigne une requête d'une page HTTPS vers une destination en HTTP simple.

Valeur	Statut	Ce qui est envoyé
`no-referrer`	✅ Bon	Rien, quelle que soit la requête.
`no-referrer-when-downgrade`	❌ Risqué	URL complète partout, rien en cas de downgrade. L'ancien défaut hérité d'avant 2020.
`origin`	✅ Bon	Origine seule, partout, même en cas de downgrade.
`origin-when-cross-origin`	✅ Bon	URL complète en same-origin, origine en cross-origin et en cas de downgrade.
`same-origin`	✅ Bon	URL complète en same-origin, rien en cross-origin.
`strict-origin`	✅ Bon	Origine seule, rien en cas de downgrade.
`strict-origin-when-cross-origin`	✅ Bon	URL complète en same-origin, origine en cross-origin, rien en cas de downgrade.
`unsafe-url`	❌ Risqué	URL complète partout, y compris en cas de downgrade.

Les noms se lisent de façon systématique : un préfixe strict- signifie que rien n'est envoyé en cas de downgrade, et un suffixe -when-cross-origin signifie que l'URL complète reste sur les requêtes same-origin tandis que moins sort en cross-origin.

Quand une page n'envoie aucune politique, tous les moteurs actuels prennent strict-origin-when-cross-origin par défaut ; Chrome, Firefox et Safari ont tous adopté ce défaut ces dernières années. Avant ce changement, le défaut était no-referrer-when-downgrade, qui envoie l'URL complète à chaque destination cross-origin.

Le header n'est pas la seule forme de livraison. Une balise <meta name="referrer" content="..."> fait le même travail dans le markup, un attribut referrerpolicy sur les éléments a, area, img, iframe, script et link définit une politique pour un seul élément, et rel="noreferrer" sur un lien omet complètement le header Referer (il implique aussi noopener).

Contre quoi cela protège

Des secrets d'URL qui fuitent vers des tiers. Les URL de capacité (liens de réinitialisation de mot de passe, liens d'invitation, URL signées), les requêtes de recherche et les données personnelles dans les chemins arrivent autrement chez chaque script d'analytics, CDN, tag publicitaire et site lié. Une politique stricte retire le chemin et la query avant que la requête ne quitte le navigateur.
La granularité du tracking cross-site. Un referrer complet indique à un tiers exactement sur quelle page l'utilisateur se trouvait, pas seulement sur quel site. N'envoyer que l'origine est une minimisation des données ; Mozilla comme Chrome ont présenté le changement de défaut comme une amélioration de la vie privée.

Ce n'est pas une défense contre le CSRF. Le header Referer est trop peu fiable pour bâtir dessus une protection contre la falsification de requête ; utilisez plutôt des jetons CSRF et vérifiez les headers Origin ou Sec-Fetch-Site côté serveur, comme le détaillent les bonnes pratiques referrer de web.dev.

Risques sans le header

Omettre le header n'est plus la fuite qu'il représentait, parce que le défaut actuel des navigateurs est déjà strict-origin-when-cross-origin. Définissez-le explicitement quand même. Les défauts varient selon les versions de navigateur et changent avec le temps (l'actuel n'est arrivé qu'entre 2020 et 2021), un navigateur plus ancien applique encore no-referrer-when-downgrade et envoie l'URL complète à chaque destination cross-origin, et une seule valeur laxiste dans une balise meta ou un attribut d'élément égaré réintroduit silencieusement la fuite. Un header explicite affirme la politique que vous avez choisie au lieu d'hériter de ce que le navigateur embarque.

Risques et pièges à l'usage

L'analytics perd le détail au niveau de la page. Avec les valeurs origine seule, les sites vers lesquels vous liez (et leurs analytics) voient https://api-next.centralcsp.com/ au lieu du chemin complet. L'attribution de source au niveau du domaine continue de fonctionner.
Vous ne pouvez pas l'assouplir partout. Safari plafonne tous les referrers cross-site à l'origine quelle que soit votre politique (Intelligent Tracking Prevention), et Firefox (avec la Tracking Protection) ignore les valeurs laxistes (unsafe-url, no-referrer-when-downgrade, origin-when-cross-origin) sur les requêtes cross-site. unsafe-url ne peut pas restaurer les referrers cross-site complets en dehors de Chromium.
Les attributs d'élément l'emportent. Un attribut referrerpolicy sur un lien, une image, un script ou une iframe remplace la politique de la page pour cet élément, dans les deux sens.
La syntaxe de repli ne marche que dans le header. Referrer-Policy: no-referrer, strict-origin-when-cross-origin est valide ; les navigateurs ignorent les valeurs inconnues et la dernière reconnue l'emporte. La syntaxe à virgule ne fonctionne pas dans l'attribut referrerpolicy.
no-referrer peut casser les contrôles fondés sur le Referer. Certains flux de paiement et de détection de fraude, ainsi que les contrôles anti hotlink, exigent un Referer ; devenir totalement silencieux sur tout le site peut les casser.

Comment le mettre en place

Définissez Referrer-Policy: strict-origin-when-cross-origin sur toutes les réponses HTML. La politique s'applique au document qui l'a reçue, donc couvrez chaque page, pas seulement la page d'accueil.
Pour les liens sortants individuellement sensibles, coupez le referrer au niveau de l'élément :
```
<a href="https://example.net/partner-portal" rel="noreferrer">Portail partenaire</a>
```
Vérifiez le header déployé, et le reste de vos headers de réponse, avec le scanner de headers de sécurité.

Recommandation

Envoyez Referrer-Policy: strict-origin-when-cross-origin sur chaque réponse HTML :

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

C'est la valeur que recommande le cheat sheet OWASP sur les headers HTTP : l'URL complète reste au sein de votre propre site, les destinations cross-origin n'obtiennent que l'origine, et rien n'est envoyé en cas de downgrade. Elle correspond au défaut actuel des navigateurs, mais définissez-la explicitement au lieu de compter sur les défauts. Si vos URL portent des secrets même en navigation same-origin (jetons de réinitialisation, URL signées), passez à no-referrer et acceptez que les contrôles fondés sur le Referer cessent de fonctionner.

Prise en charge par les navigateurs

Baseline largement disponible : le header est pris en charge dans tous les navigateurs actuels, donc la prise en charge est de fait universelle, et tous les moteurs actuels prennent strict-origin-when-cross-origin par défaut quand aucune politique n'est définie. Les navigateurs peuvent aussi être plus stricts que votre politique : Safari plafonne les referrers cross-site à l'origine quoi qu'il arrive (Intelligent Tracking Prevention), et Firefox ignore les valeurs laxistes sur les requêtes cross-site avec la Tracking Protection.

FAQ

Qu'est-ce que strict-origin-when-cross-origin ?

C'est la politique par défaut dans tous les navigateurs actuels. Sur les requêtes same-origin, elle envoie l'URL complète, c'est-à-dire l'origine, le chemin et la query. Sur les requêtes cross-origin, elle n'envoie que votre origine. En cas de downgrade de HTTPS vers HTTP, elle n'envoie rien. Elle garde chemins et queries hors des autres sites tout en préservant l'attribution au niveau du domaine.

Referrer-Policy casse-t-il Google Analytics ?

Non. Une politique plus stricte réduit la granularité du referrer, donc un site de destination et vos rapports d'entrée voient votre origine plutôt que le chemin complet, mais l'attribution de source au niveau du domaine continue de fonctionner. Les analytics qui regroupent le trafic par domaine référent ne sont pas affectées ; seul le détail du referrer au niveau du chemin est rogné sur les requêtes cross-origin.

Quelle est la différence entre referer et referrer ?

Referer est le header de requête que le navigateur attache, et son nom est une faute d'orthographe historique restée dans le standard HTTP. Referrer-Policy, le header de réponse qui le contrôle, et document.referrer, la propriété JavaScript qui l'expose, s'écrivent tous deux correctement. Même concept, un mot mal orthographié pour la compatibilité.

Voir aussi

Vue d'ensemble des headers de sécurité
La directive CSP referrer, retirée, que ce header a remplacée
Strict-Transport-Security, qui supprime les sauts en HTTP simple contre lesquels les valeurs strict- protègent
Scanner de headers de sécurité pour vérifier vos headers déployés

Referrer-Policy