Bonnes pratiques en matière de règles relatives aux URL de provenance et aux sites référents

Maud Nalpas

Cette page décrit quelques bonnes pratiques pour définir votre Referrer-Policy et utiliser l'en-tête Referer dans les requêtes entrantes.

Résumé

• Les fuites d'informations interorigines inattendues nuisent à la confidentialité des utilisateurs Web. Une règle de provenance protectrice peut vous aider.
• Envisagez de définir une règle d'URL de provenance sur strict-origin-when-cross-origin. Elle préserve la majeure partie de l'utilité du site référent, tout en limitant le risque de fuite de données interorigines.
• N'utilisez pas de référents pour la protection contre la falsification de requêtes intersites (CSRF). Utilisez plutôt des jetons CSRF et d'autres en-têtes comme couche de sécurité supplémentaire.

Remarque :

• Si vous ne connaissez pas la différence entre "site" et "origine", consultez Comprendre les concepts de "same-site" et "same-origin".
• Il manque un "R" dans l'en-tête Referer en raison d'une faute d'orthographe dans la spécification d'origine. L'en-tête Referrer-Policy et referrer en JavaScript et le DOM sont correctement orthographiés.

Présentation de Referer et Referrer-Policy

Les requêtes HTTP peuvent inclure un en-tête Referer facultatif, qui indique l'origine ou l'URL de la page Web à partir de laquelle la requête a été effectuée. L'en-tête Referrer-Policy définit les données disponibles dans l'en-tête Referer.

Dans l'exemple suivant, l'en-tête Referer inclut l'URL complète de la page sur site-one à partir de laquelle la requête a été effectuée.

Une requête HTTP avec un en-tête Referer.

L'en-tête Referer peut être présent dans différents types de requêtes :

• Requêtes de navigation, lorsqu'un utilisateur clique sur un lien.
• Requêtes de sous-ressources, lorsqu'un navigateur demande des images, des iFrames, des scripts et d'autres ressources dont une page a besoin.

Pour les navigations et les iFrames, vous pouvez également accéder à ces données avec JavaScript à l'aide de document.referrer.

Vous pouvez en apprendre beaucoup sur les valeurs Referer. Par exemple, un service d'analyse peut les utiliser pour déterminer que 50 % des visiteurs de site-two.example proviennent de social-network.example. Toutefois, lorsque l'URL complète, y compris le chemin d'accès et la chaîne de requête, est envoyée dans l'Referer entre les origines, cela peut mettre en danger la confidentialité des utilisateurs et créer des risques de sécurité :

L'utilisation de l'URL complète peut avoir un impact sur la confidentialité et la sécurité des utilisateurs.

Les URL 1 à 5 contiennent des informations privées, et parfois des informations sensibles ou permettant d'identifier l'utilisateur. La fuite silencieuse de ces informations entre différentes origines peut compromettre la confidentialité des utilisateurs Web.

L'URL 6 est une URL de fonctionnalité. Si une personne autre que l'utilisateur prévu reçoit ce code, une personne malveillante peut prendre le contrôle du compte de cet utilisateur.

Pour limiter les données de provenance disponibles pour les requêtes provenant de votre site, vous pouvez définir une règle de provenance.

Quelles sont les règles disponibles et en quoi diffèrent-elles ?

Vous pouvez sélectionner l'une des huit règles. Selon la règle, les données disponibles dans l'en-tête Referer (et document.referrer) peuvent être :

• Aucune donnée (aucun en-tête Referer n'est présent)
• Seule l'origine
• L'URL complète : origine, chemin d'accès et chaîne de requête

Exemples de données de provenance.

Certaines règles sont conçues pour se comporter différemment en fonction du contexte : requête interorigine ou de même origine, si la destination de la requête est aussi sécurisée que l'origine, ou les deux. Cela permet de limiter la quantité d'informations partagées entre les origines ou vers des origines moins sécurisées, tout en conservant la richesse du site référent sur votre propre site.

Le tableau suivant montre comment les règles de provenance limitent les données d'URL disponibles à partir de l'en-tête Referer et de document.referrer :

Champ d'application des règles	Nom de la règle	Référent : aucune donnée	Referer: Origin only	Référent : URL complète
Ne tient pas compte du contexte de la requête	no-referrer	check
	origin		check
	unsafe-url			check
Axé sur la sécurité	strict-origin	Requête HTTPS vers HTTP	Requête HTTPS vers HTTPS ou HTTP vers HTTP
	no-referrer-when-downgrade	Requête HTTPS vers HTTP		Requête de HTTPS vers HTTPS ou de HTTP vers HTTP
Axé sur la confidentialité	origin-when-cross-origin		Requête interorigine	Requête de même origine
	same-origin	Requête interorigine		Requête de même origine
Axé sur la confidentialité et la sécurité	strict-origin-when-cross-origin	Requête HTTPS vers HTTP	Requête interorigine de HTTPS vers HTTPS ou de HTTP vers HTTP	Requête de même origine

MDN fournit une liste complète de règles et d'exemples de comportement.

Voici quelques points à prendre en compte lorsque vous définissez une règle de provenance :

• Toutes les règles qui prennent en compte le schéma (HTTPS ou HTTP) (strict-origin, no-referrer-when-downgrade et strict-origin-when-cross-origin) traitent les requêtes d'une origine HTTP vers une autre origine HTTP de la même manière que les requêtes d'une origine HTTPS vers une autre origine HTTPS, même si le protocole HTTP est moins sécurisé. En effet, pour ces règles, ce qui importe, c'est de savoir si une dégradation de la sécurité a lieu, c'est-à-dire si la requête peut exposer des données d'une origine chiffrée à une origine non chiffrée, comme dans les requêtes HTTPS → HTTP. Une requête HTTP → HTTP n'est pas du tout chiffrée. Il n'y a donc pas de rétrogradation.
• Si une requête est same-origin, cela signifie que le schéma (HTTPS ou HTTP) est le même. Il n'y a donc pas de dégradation de la sécurité.

Règles par défaut en matière d'URL de provenance dans les navigateurs

En octobre 2021

Si aucune règle de provenance n'est définie, le navigateur utilise sa règle par défaut.

Navigateur	Referrer-Policy par défaut/Comportement
Chrome	La valeur par défaut est strict-origin-when-cross-origin.
Firefox	La valeur par défaut est strict-origin-when-cross-origin. À partir de la version 93, pour les utilisateurs de la protection stricte contre le suivi et de la navigation privée, les règles de provenance moins restrictives no-referrer-when-downgrade, origin-when-cross-origin et unsafe-url sont ignorées pour les requêtes intersites. Cela signifie que la provenance est toujours tronquée pour les requêtes intersites, quelle que soit la règle du site Web.
Edge	La valeur par défaut est strict-origin-when-cross-origin.
Safari	La valeur par défaut est semblable à strict-origin-when-cross-origin, avec quelques différences spécifiques. Pour en savoir plus, consultez Empêcher le suivi de la prévention du suivi.

Bonnes pratiques pour définir une règle de provenance

Objectif : définir explicitement une règle de protection de la confidentialité, telle que strict-origin-when-cross-origin(ou plus stricte).

Il existe différentes façons de définir des règles de provenance pour votre site :

• En tant qu'en-tête HTTP
• Dans votre code HTML
• À partir de JavaScript, pour chaque requête

Vous pouvez définir des règles différentes pour différentes pages, requêtes ou éléments.

L'en-tête HTTP et l'élément Meta sont tous deux au niveau de la page. L'ordre de priorité pour déterminer la stratégie effective d'un élément est le suivant :

1. Règle au niveau des éléments
2. Règle au niveau de la page
3. Navigateur par défaut

Exemple :

index.html :

<meta name="referrer" content="strict-origin-when-cross-origin" />
<img src="..." referrerpolicy="no-referrer-when-downgrade" />

L'image est demandée avec une règle no-referrer-when-downgrade, et toutes les autres requêtes de sous-ressources de cette page suivent la règle strict-origin-when-cross-origin.

Comment afficher la règle de provenance ?

securityheaders.com est pratique pour déterminer la stratégie utilisée par un site ou une page spécifique.

Vous pouvez également utiliser les outils pour les développeurs dans Chrome, Edge ou Firefox pour afficher la règle de provenance utilisée pour une requête spécifique. Au moment de la rédaction de ce document, Safari n'affiche pas l'en-tête Referrer-Policy, mais affiche l'en-tête Referer qui a été envoyé.

Panneau Réseau des outils pour les développeurs Chrome avec une requête sélectionnée.

Quelle règle devez-vous définir pour votre site Web ?

Nous vous recommandons vivement de définir explicitement une règle d'amélioration de la confidentialité, telle que strict-origin-when-cross-origin (ou plus stricte).

Pourquoi "explicitement" ?

Si vous ne définissez pas de règle de provenance, la règle par défaut du navigateur sera utilisée. En fait, les sites Web s'en remettent souvent à la règle par défaut du navigateur. Mais ce n'est pas l'idéal, car :

• Les règles par défaut varient d'un navigateur à l'autre. Par conséquent, si vous vous fiez aux valeurs par défaut du navigateur, le comportement de votre site ne sera pas prévisible d'un navigateur à l'autre.
• Les navigateurs adoptent des valeurs par défaut plus strictes, telles que strict-origin-when-cross-origin, et des mécanismes tels que la suppression de l'URL de provenance pour les requêtes interorigines. En activant explicitement une règle d'amélioration de la confidentialité avant que les paramètres par défaut du navigateur ne changent, vous gardez le contrôle et pouvez effectuer des tests comme bon vous semble.

Pourquoi strict-origin-when-cross-origin (ou plus strict) ?

Vous avez besoin d'une règle sécurisée, qui améliore la confidentialité et qui est utile. La définition de "utile" dépend de ce que vous attendez de l'URL de provenance :

• Sécurisé : si votre site Web utilise HTTPS (si ce n'est pas le cas, faites-en une priorité), vous ne voulez pas que les URL de votre site Web soient divulguées dans des requêtes non HTTPS. Étant donné que n'importe qui sur le réseau peut les voir, les fuites exposeraient vos utilisateurs à des attaques de l'intercepteur. Les règles no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer et strict-origin résolvent ce problème.
• Amélioration de la confidentialité : pour une requête interorigine, no-referrer-when-downgrade partage l'URL complète, ce qui peut entraîner des problèmes de confidentialité. strict-origin-when-cross-origin et strict-origin ne partagent que l'origine, et no-referrer ne partage rien du tout. Il vous reste donc strict-origin-when-cross-origin, strict-origin et no-referrer comme options d'amélioration de la confidentialité.
• Utile : no-referrer et strict-origin ne partagent jamais l'URL complète, même pour les requêtes de même origine. Si vous avez besoin de l'URL complète, strict-origin-when-cross-origin est une meilleure option.

Tout cela signifie que strict-origin-when-cross-origin est généralement un choix judicieux.

Exemple : Définir une règle strict-origin-when-cross-origin

index.html :

<meta name="referrer" content="strict-origin-when-cross-origin" />

Ou côté serveur, par exemple dans Express :

const helmet = require('helmet');
app.use(helmet.referrerPolicy({policy: 'strict-origin-when-cross-origin'}));

Que se passe-t-il si strict-origin-when-cross-origin (ou une règle plus stricte) ne répond pas à tous vos cas d'utilisation ?

Dans ce cas, adoptez une approche progressive : définissez une règle de protection telle que strict-origin-when-cross-origin pour votre site Web et, si nécessaire, une règle plus permissive pour des requêtes ou des éléments HTML spécifiques.

Exemple : Règle au niveau de l'élément

index.html :

<head>
  <!-- document-level policy: strict-origin-when-cross-origin -->
  <meta name="referrer" content="strict-origin-when-cross-origin" />
  <head>
    <body>
      <!-- policy on this <a> element: no-referrer-when-downgrade -->
      <a src="…" href="…" referrerpolicy="no-referrer-when-downgrade"></a>
      <body></body>
    </body>
  </head>
</head>

Safari/WebKit peut limiter document.referrer ou l'en-tête Referer pour les requêtes intersites. En savoir plus

Exemple : Règle au niveau de la requête

script.js :

fetch(url, {referrerPolicy: 'no-referrer-when-downgrade'});

Quels autres éléments devez-vous prendre en compte ?

Votre stratégie doit dépendre de votre site Web et de vos cas d'utilisation, tels que déterminés par vous, votre équipe et votre entreprise. Si certaines URL contiennent des données d'identification ou sensibles, définissez une règle de protection.

Avertissement : Des données qui ne vous semblent pas sensibles peuvent l'être pour vos utilisateurs, ou ils peuvent tout simplement ne pas vouloir ou ne pas s'attendre à ce qu'elles soient divulguées de manière silencieuse interorigine.

Bonnes pratiques pour les requêtes entrantes

Voici quelques consignes à suivre si votre site utilise l'URL de provenance des requêtes entrantes.

Protéger les données des utilisateurs

Le Referer peut contenir des données privées, personnelles ou d'identification. Veillez donc à le traiter comme tel.

Les référents entrants peuvent changer {referer-can-change}

L'utilisation du référent des requêtes interorigines entrantes présente quelques limites :

• Si vous n'avez aucun contrôle sur l'implémentation de l'émetteur de la requête, vous ne pouvez pas faire d'hypothèses sur l'en-tête Referer (et document.referrer) que vous recevez. L'émetteur de la requête peut décider de passer à une règle no-referrer à tout moment ou, plus généralement, à une règle plus stricte que celle qu'il utilisait auparavant. Cela signifie que vous recevez moins de données de Referer qu'auparavant.
• Les navigateurs utilisent de plus en plus la règle Referrer-Policy strict-origin-when-cross-origin par défaut. Cela signifie que vous ne recevrez peut-être plus que l'origine, au lieu d'une URL de provenance complète, dans les requêtes interorigines entrantes, si le site de l'expéditeur n'a pas défini de règle.
• Les navigateurs peuvent modifier la façon dont ils gèrent Referer. Par exemple, certains développeurs de navigateurs peuvent décider de toujours réduire les référents aux origines dans les requêtes de sous-ressources interorigines, afin de protéger la confidentialité des utilisateurs.
• L'en-tête Referer (et document.referrer) peut contenir plus de données que nécessaire. Par exemple, il peut contenir une URL complète alors que vous souhaitez uniquement savoir si la requête est interorigine.

Alternatives à Referer

Vous devrez peut-être envisager d'autres solutions si :

• Une fonctionnalité essentielle de votre site utilise l'URL de provenance des requêtes interorigines entrantes.
• Votre site ne reçoit plus la partie de l'URL de provenance dont il a besoin dans une requête interorigine. Cela se produit lorsque l'émetteur de la requête modifie sa règle ou lorsqu'aucune règle n'est définie et que la règle par défaut du navigateur a changé (comme dans Chrome 85).

Pour définir des alternatives, commencez par analyser la partie du site référent que vous utilisez.

Si vous n'avez besoin que de l'origine

• Si vous utilisez l'URL de provenance dans un script qui dispose d'un accès de niveau supérieur à la page, window.location.origin est une alternative.
• S'ils sont disponibles, les en-têtes tels que Origin et Sec-Fetch-Site vous fournissent l'Origin ou indiquent si la requête est interorigine, ce qui peut correspondre exactement à ce dont vous avez besoin.

Si vous avez besoin d'autres éléments de l'URL (chemin d'accès, paramètres de requête, etc.)

• Les paramètres de requête peuvent répondre à votre cas d'utilisation, ce qui vous évite d'avoir à analyser l'URL de provenance.
• Si vous utilisez l'URL de provenance dans un script qui dispose d'un accès de niveau supérieur à la page, window.location.pathname peut être une alternative. Extrayez uniquement la section du chemin d'accès de l'URL et transmettez-la en tant qu'argument, afin que les informations potentiellement sensibles des paramètres d'URL ne soient pas transmises.

Si vous ne pouvez pas utiliser ces alternatives :

• Vérifiez si vous pouvez modifier vos systèmes pour que l'émetteur de la requête (par exemple, site-one.example) définisse explicitement les informations dont vous avez besoin dans une sorte de configuration.
  • Avantages : plus explicite, plus respectueux de la confidentialité pour les utilisateurs de site-one.example, plus pérenne.
  • Inconvénient : cela peut nécessiter plus de travail de votre part ou de celle des utilisateurs de votre système.
• Vérifiez si le site qui émet les requêtes peut accepter de définir une valeur no-referrer-when-downgrade pour l'en-tête Referrer-Policy par élément ou par requête.
  • Inconvénient : potentiellement moins respectueux de la confidentialité pour les utilisateurs de site-one.example, potentiellement non compatible avec tous les navigateurs.

Protection contre la falsification de requêtes intersites (CSRF)

Un émetteur de requête peut toujours décider de ne pas envoyer l'URL de provenance en définissant une règle no-referrer, et une personne malveillante peut même usurper l'URL de provenance.

Utilisez des jetons CSRF comme protection principale. Pour une protection supplémentaire, utilisez SameSite et, au lieu de Referer, utilisez des en-têtes tels que Origin (disponible sur les requêtes POST et CORS) et Sec-Fetch-Site s'il est disponible.

Journaliser et déboguer

Veillez à protéger les données personnelles ou sensibles des utilisateurs qui pourraient se trouver dans le Referer.

Si vous n'utilisez que l'origine, vérifiez si vous pouvez utiliser l'en-tête Origin comme alternative. Cela peut vous fournir les informations dont vous avez besoin pour le débogage de manière plus simple et sans avoir à analyser l'URL de provenance.

Paiements

Les fournisseurs de services de paiement peuvent s'appuyer sur l'en-tête Referer des requêtes entrantes pour effectuer des contrôles de sécurité.

Exemple :

• L'utilisateur clique sur un bouton Acheter sur online-shop.example/cart/checkout.
• online-shop.example redirige vers payment-provider.example pour gérer la transaction.
• payment-provider.example compare le Referer de cette requête à une liste de valeurs Referer autorisées configurées par les marchands. Si elle ne correspond à aucune entrée de la liste, payment-provider.example rejette la requête. Si c'est le cas, l'utilisateur peut procéder à la transaction.

Bonnes pratiques pour les contrôles de sécurité du flux de paiement

En tant que fournisseur de services de paiement, vous pouvez utiliser le Referer comme vérification de base contre certaines attaques. Toutefois, l'en-tête Referer ne constitue pas une base fiable pour une vérification. Le site demandeur, qu'il s'agisse d'un marchand légitime ou non, peut définir une règle no-referrer qui rend les informations Referer indisponibles pour le fournisseur de services de paiement.

L'examen de Referer peut aider les fournisseurs de services de paiement à détecter les pirates informatiques naïfs qui n'ont pas défini de règle no-referrer. Si vous utilisez Referer comme première vérification :

• Ne vous attendez pas à ce que Referer soit toujours présent. S'il est présent, vérifiez-le uniquement par rapport aux données minimales qu'il peut inclure, à savoir l'origine.
  • Lorsque vous définissez la liste des valeurs Referer autorisées, veillez à n'inclure que l'origine et aucun chemin d'accès.
  • Par exemple, les valeurs Referer autorisées pour online-shop.example doivent être online-shop.example, et non online-shop.example/cart/checkout. En n'attendant aucun Referer ou une valeur Referer qui n'est que l'origine du site demandeur, vous évitez les erreurs pouvant provenir d'hypothèses sur l'Referrer-Policy du marchand.
• Si l'en-tête Referer est absent, ou s'il est présent et que la vérification de l'origine Referer de base réussit, vous pouvez passer à une autre méthode de validation plus fiable.

Pour vérifier les paiements de manière plus fiable, laissez le demandeur hacher les paramètres de requête avec une clé unique. Les fournisseurs de services de paiement peuvent ensuite calculer le même hachage de votre côté et n'accepter la requête que si elle correspond à votre calcul.

Qu'advient-il de l'Referer lorsqu'un site marchand HTTP sans stratégie de provenance redirige vers un fournisseur de services de paiement HTTPS ?

Aucun Referer n'est visible dans la requête adressée au fournisseur de services de paiement HTTPS, car la plupart des navigateurs utilisent strict-origin-when-cross-origin ou no-referrer-when-downgrade par défaut lorsqu'un site Web n'a pas de règle définie. Le passage de Chrome à une nouvelle règle par défaut ne modifiera pas ce comportement.

Remarque : Si votre site Web utilise le protocole HTTP, migrez vers HTTPS.

Conclusion

Une règle de provenance protectrice est un excellent moyen d'offrir plus de confidentialité à vos utilisateurs.

Pour en savoir plus sur les différentes techniques permettant de protéger vos utilisateurs, consultez notre collection Sûr et sécurisé.

Ressources

• Comprendre les concepts "same-site" et "same-origin"
• Un nouvel en-tête de sécurité : Referrer Policy (2017)
• Referrer-Policy sur MDN
• En-tête Referer : problèmes de confidentialité et de sécurité sur MDN
• Modification de Chrome : intention d'implémentation de Blink
• Modification de Chrome : intention de livraison de Blink
• Modification de Chrome : entrée d'état
• Modification de Chrome : article de blog sur la version bêta 85
• Fil de discussion GitHub sur la suppression des référents : ce que font les différents navigateurs
• Spécification Referrer-Policy

Nous remercions chaleureusement tous les examinateurs pour leurs contributions et leurs commentaires, en particulier Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck et Kayce Basques.