# Referrer-Policy (/fr/docs/web-security/security-headers/referrer-policy)



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](#recommandation)) :

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

## Valeurs et ce que fait chacune [#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 [#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](https://web.dev/articles/referrer-best-practices).

## Risques sans le header [#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 [#risques-et-pièges-à-lusage]

* **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://example.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 [#comment-le-mettre-en-place]

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

2. Pour les liens sortants individuellement sensibles, coupez le referrer au
   niveau de l'élément :

   ```html
   <a href="https://example.net/partner-portal" rel="noreferrer">Portail partenaire</a>
   ```

3. Vérifiez le header déployé, et le reste de vos headers de réponse, avec le
   [scanner de headers de sécurité](/tools/security-headers).

## Recommandation [#recommandation]

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

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

C'est la valeur que recommande le
[cheat sheet OWASP sur les headers HTTP](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html) :
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 [#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 [#faq]

### Qu'est-ce que strict-origin-when-cross-origin ? [#quest-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 ? [#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 ? [#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 [#voir-aussi]

* [Vue d'ensemble des headers de sécurité](/fr/docs/web-security/security-headers)
* [La directive CSP referrer, retirée](/fr/docs/web-security/policies/content-security-policy/directives/referrer),
  que ce header a remplacée
* [Strict-Transport-Security](/fr/docs/web-security/security-headers/strict-transport-security),
  qui supprime les sauts en HTTP simple contre lesquels les valeurs `strict-`
  protègent
* [Scanner de headers de sécurité](/tools/security-headers) pour vérifier
  vos headers déployés

## Sources [#sources]

* [W3C, brouillon d'éditeur Referrer Policy](https://w3c.github.io/webappsec-referrer-policy/)
* [MDN, Referrer-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy)
* [MDN, Referer](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referer)
* [web.dev, bonnes pratiques Referer et Referrer-Policy](https://web.dev/articles/referrer-best-practices)
* [OWASP, cheat sheet des headers HTTP](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Headers_Cheat_Sheet.html)
* [Chrome, un nouveau Referrer-Policy par défaut](https://developer.chrome.com/blog/referrer-policy-new-chrome-default)
* [Mozilla, protections anti-tracking du referrer dans Firefox](https://blog.mozilla.org/security/2021/10/05/firefox-93-features-an-improved-smartblock-and-new-referrer-tracking-protections/)