Skip to content

Glossary

Referer

En-tête HTTP traçant l’URL d’origine

By Published Updated

L’en-tête Referer (oui, mal orthographié — la spec HTTP de 1996 a établi la forme canonique comme “Referer” et la faute de frappe est devenue standard) est envoyé par les navigateurs sur la plupart des requêtes, contenant l’URL de la page sur laquelle se trouvait l’utilisateur lorsqu’il a déclenché la requête.

Utilisé pour :

  • Analyse web — “d’où vient ce trafic ?”
  • Prévention du hotlinking — les hébergeurs d’images vérifient que les requêtes proviennent de sites approuvés.
  • Défense en profondeur CSRF — certaines applications vérifient que le Referer correspond à l’origine attendue.
  • Attribution d’affiliation — suivi du site partenaire qui a généré une conversion.

Problème de confidentialité moderne : l’URL complète — y compris les jetons, les requêtes de recherche ou les données personnelles dans le chemin de l’URL — fuit vers toutes les ressources tierces chargées par la page. L’en-tête de réponse Referrer-Policy (noté : correctement orthographié cette fois) contrôle la quantité d’informations de référent que les navigateurs envoient :

  • no-referrer : ne jamais envoyer d’en-tête Referer.
  • same-origin : envoyer l’URL complète pour les requêtes de même origine, rien pour les autres.
  • strict-origin-when-cross-origin : envoyer uniquement l’origine pour les requêtes HTTPS cross-origin. Comportement par défaut des navigateurs modernes.
  • unsafe-url : toujours envoyer l’URL complète. À éviter.

Pour les applications sensibles à la confidentialité, définissez une politique stricte sur chaque réponse.

La célèbre faute de frappe : l’en-tête a été initialement proposé en 1995 par Phillip Hallam-Baker, et la spec a mal orthographié “Referrer” en “Referer” avant que l’erreur ne soit remarquée. Le temps que quelqu’un s’en aperçoive, plusieurs implémentations majeures étaient déjà en production. La RFC 1945 a figé la faute d’orthographe comme canonique. Lorsque le W3C a ajouté un en-tête de politique en 2014, ils l’ont délibérément orthographié correctement (Referrer-Policy) pour le différencier de l’en-tête de requête hérité.

Ce que les navigateurs modernes envoient par défaut : depuis Chrome 85 (août 2020), Firefox 87 (mars 2021) et Safari 14, la politique par défaut est strict-origin-when-cross-origin. Les requêtes cross-origin ne reçoivent maintenant que l’origine (https://example.com), pas l’URL complète. Les requêtes de même origine reçoivent toujours l’URL complète. Ce seul changement a éliminé une décennie de fuites accidentelles de jetons d’URL vers des scripts d’analyse et de publicité tiers. Référence : W3C — Referrer Policy.

Exemple concret : fuite de l’URL de réinitialisation de mot de passe

Un schéma de violation courant : une application envoie par e-mail un lien de réinitialisation de mot de passe de la forme https://app.example.com/reset?token=abc123def456.... L’utilisateur clique ; la page de réinitialisation se charge et inclut Google Analytics, Facebook Pixel et une bibliothèque de graphiques depuis un CDN. Sous l’ancienne politique par défaut (pré-2020), chaque requête tierce portait Referer: https://app.example.com/reset?token=abc123def456... — exposant le jeton de réinitialisation aux journaux de serveur de plusieurs fournisseurs. Sous la valeur par défaut moderne strict-origin-when-cross-origin, les requêtes cross-origin ne portent que Referer: https://app.example.com et le jeton reste privé. Encore mieux, définissez Referrer-Policy: no-referrer sur chaque réponse de flux sensible.

Ce qui fuit encore malgré la politique

Referrer-Policy ne régit que l’en-tête Referer. Les jetons d’URL apparaissent encore dans l’historique du navigateur, dans la propriété JavaScript document.referrer visible par les scripts de même origine, dans les instructions de journal window.location et dans tout SDK de surveillance des erreurs qui capture les URL. La solution architecturale est de placer les jetons sensibles dans le corps de la requête ou dans un cookie à courte durée de vie défini immédiatement à l’atterrissage, puis de rediriger vers une URL sans le jeton. Référence : RFC 9110 — Sémantique HTTP §10.1.3 (Referer).

Frequently asked questions

Qu’est-ce que l’en-tête HTTP Referer ?
L’en-tête Referer est un en-tête de requête HTTP contenant l’URL de la page qui a lié à la ressource actuelle. Il indique aux serveurs d’où vient le trafic — quelle page, quel résultat de recherche ou quel site a envoyé l’utilisateur.
Pourquoi Referer est-il mal orthographié et en quoi cela importe-t-il ?
L’en-tête a été mal orthographié Referer (au lieu de Referrer) dans la spécification HTTP/1.0 de 1996. Comme le corriger casserait chaque serveur et client qui l’analyse, la faute d’orthographe est intentionnellement conservée dans la spec et ne peut pas être corrigée.
Quelle est la différence entre Referer et Referrer-Policy ?
Referer est l’en-tête de requête que les navigateurs envoient ; Referrer-Policy est un en-tête de réponse (ou une balise meta) qui contrôle la quantité d’URL incluse dans l’en-tête Referer. Définir Referrer-Policy à no-referrer supprime entièrement l’en-tête pour les pages sensibles à la confidentialité.

Related

Published May 15, 2026 · Last reviewed May 31, 2026