Définissez une Referrer-Policy stricte

Ce que vérifie ce contrôle

Inspecte les en-têtes de réponse à la recherche d’une directive Referrer-Policy et vérifie que la valeur est l’une des politiques sûres : strict-origin-when-cross-origin (le défaut des navigateurs modernes), strict-origin, same-origin, no-referrer ou no-referrer-when-downgrade. Le contrôle échoue lorsque l’en-tête est manquant ou défini sur une politique qui fuit (unsafe-url, origin-when-cross-origin sans strict-).

Pourquoi c’est important

L’en-tête de requête Referer (oui, mal orthographié dans la RFC d’origine et on s’en accommode) indique à chaque site sur lequel vous cliquez depuis quelle URL vous venez. Sans politique, le navigateur envoie l’URL complète — chemin, query string et fragment.

C’est un trou de confidentialité plus large que la plupart des gens l’imaginent.

• Fuite de tokens. Les liens de réinitialisation de mot de passe, les URL de magic-login, les callbacks OAuth et les URL « partager via ce lien privé » portent tous des secrets dans le chemin ou la query. Chaque ressource externe de la page (analytics, polices, scripts tiers, images intégrées, liens sortants) reçoit l’URL complète comme Referer.
• Fuite de données personnelles. Des URL comme /users/jane-patel@example.com/profile ou /checkout?email=… fuient des données personnelles vers les régies publicitaires et outils analytiques.
• Découverte de chemins admin. Un clic depuis /admin/users/42 vers une image externe annonce silencieusement l’existence de /admin/ à tout service externe.
• Exposition RGPD. Envoyer des données personnelles à un réseau publicitaire basé aux US sans consentement est une violation RGPD, peu importe l’intention. Une politique de referrer stricte est une mitigation peu coûteuse.

Les navigateurs modernes (Chrome 85+, Firefox 87+, Safari 14+) livrent strict-origin-when-cross-origin par défaut, mais seulement quand la page ne retourne aucune politique. Les anciens navigateurs et les cas limites (origines file://, navigations http→http) fuitent encore tant que vous ne définissez pas un en-tête explicitement.

Comment le corriger

Choisissez l’une des politiques sûres et définissez-la dans vos en-têtes de réponse :

Politique	Même origine	Origine croisée	Rétrogradation cross-origin (https→http)
no-referrer	rien	rien	rien
same-origin	URL complète	rien	rien
strict-origin	origine uniquement	origine uniquement	rien
strict-origin-when-cross-origin (recommandé)	URL complète	origine uniquement	rien

strict-origin-when-cross-origin est le défaut moderne : vos navigations internes obtiennent les URL complètes (utile pour les analytics), les liens externes n’obtiennent que l’origine (https://example.com/), et les rétrogradations vers HTTP n’envoient rien.

nginx :

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

Apache :

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

Caddy :

header Referrer-Policy "strict-origin-when-cross-origin"

Cloudflare — Rules → Transform Rules → Modify Response Header, définissez globalement.

Next.js (next.config.js) :

module.exports = {
  async headers() {
    return [{
      source: "/(.*)",
      headers: [
        { key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
      ],
    }];
  },
};

Express avec Helmet :

import helmet from "helmet";
app.use(helmet.referrerPolicy({ policy: "strict-origin-when-cross-origin" }));

Surcharge par lien. Si un lien spécifique a besoin d’un comportement referrer différent, utilisez l’attribut referrerpolicy sur <a> ou <img> :

<a href="https://partner.example.com/" referrerpolicy="no-referrer">Partenaire</a>

Vérifiez vous-même :

curl -sI https://votredomaine.com/ | grep -i referrer-policy

Attendez-vous à une seule ligne avec la politique choisie. Si grep ne retourne rien, l’en-tête est manquant.

Questions fréquentes

Cela va-t-il casser mes analytics ?

Non, tant que vos analytics sont same-origin (sur votre domaine) ou auto-hébergés. Les outils analytics cross-origin qui reposent sur les URL referrer complètes (certains outils d’attribution) verront moins de données avec strict-origin-when-cross-origin, mais ils obtiennent toujours l’origine — généralement suffisant pour attribuer la visite.

Dois-je utiliser no-referrer pour être au plus sûr ?

no-referrer est le plus sûr mais casse de nombreux flux légitimes : les passerelles de paiement vérifient souvent le referrer pour confirmer qu’un paiement vient d’un site marchand réel ; les fournisseurs OAuth journalisent parfois le referrer pour la détection de fraude ; les analytics se cassent. strict-origin-when-cross-origin est le bon défaut.

Cela affecte-t-il le SEO ?

Non. Les moteurs de recherche ne lisent pas la politique de referrer. L’en-tête n’affecte que les clics sortants et le chargement de ressources. Côté SEO c’est neutre ; côté confidentialité c’est une amélioration significative.