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

Maud Nalpas

Cette page présente quelques bonnes pratiques pour définir votre règle d'URL de provenance et utiliser l'URL de provenance dans les requêtes entrantes.

Résumé

• La fuite inattendue d'informations multi-origines nuit à la confidentialité des utilisateurs du Web. Une règle d'URL de provenance protectrice peut être utile.
• Envisagez de définir une règle d'URL de provenance strict-origin-when-cross-origin. Elle préserve la plupart de l'utilité de l'URL de provenance, tout en atténuant le risque de fuite de données multi-origines.
• N'utilisez pas d'URL de provenance pour la protection contre la contrefaçon de requêtes intersites (CSRF). Utilisez des jetons CSRF plutôt et d'autres en-têtes comme couche de sécurité supplémentaire.

Principes de base de Referer et de 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' Referrer-Policy en-tête définit les données mises à disposition dans l'Referer en-tête.

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.

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-ressource, 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 apprendre beaucoup des 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 le Referer multi-origines, cela peut mettre en danger la confidentialité des utilisateurs et créer des risques de sécurité :

Les URL 1 à 5 contiennent des informations privées, et parfois des informations sensibles ou permettant d'identifier une personne. La fuite de ces informations de manière silencieuse multi-origines peut compromettre la confidentialité des utilisateurs du Web.

L'URL 6 est une URL de capacité. Si une personne autre que l'utilisateur prévu la reçoit, un acteur malveillant peut prendre le contrôle du compte de cet utilisateur.

Pour limiter les données d'URL de provenance mises à disposition pour les requêtes provenant de votre site, vous pouvez définir une règle d'URL 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 à partir de l'en-tête Referer (et de document.referrer) peuvent être les suivantes :

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

Certaines règles sont conçues pour se comporter différemment selon le contexte: requête multi-origines ou de même origine, que la destination de la requête soit aussi sécurisée que l'origine, ou les deux. Cela est utile pour limiter la quantité d'informations partagées multi-origines ou avec des origines moins sécurisées, tout en conservant la richesse de l'URL de provenance au sein de votre propre site.

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

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

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

• Toutes les règles qui tiennent compte du schéma (HTTPS par rapport à 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 HTTP est moins sécurisé. En effet, pour ces règles, ce qui compte, c'est si une rétrogradation 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 chiffrée, il n'y a donc pas de rétrogradation.
• Si une requête est de même origine, cela signifie que le schéma (HTTPS ou HTTP) est le même, il n'y a donc pas de rétrogradation de la sécurité.

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

Depuis octobre 2021

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

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

Vous pouvez définir des règles d'URL de provenance pour votre site de différentes manières :

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

Vous pouvez définir différentes règles 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 règle effective d'un élément est le suivant :

1. Règle au niveau de l'élément
2. Règle au niveau de la page
3. Valeur par défaut du navigateur

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-ressource de cette page suivent la règle strict-origin-when-cross-origin.

Comment afficher la règle d'URL de provenance ?

securityheaders.com est pratique pour déterminer la règle 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 d'URL de provenance utilisée pour une requête spécifique. Au moment de la rédaction de cet article, Safari n'affiche pas l'en-tête Referrer-Policy, mais affiche le Referer qui a été envoyé.

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

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

Pourquoi "explicitement" ?

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

• Les différents navigateurs ont des règles par défaut différentes. Par conséquent, si vous vous fiez aux valeurs par défaut du navigateur, votre site ne se comportera pas de manière prévisible sur tous les navigateurs.
• 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 multi-origines. En optant explicitement pour une règle qui améliore la confidentialité avant que les valeurs par défaut du navigateur ne changent, vous gardez le contrôle et pouvez exécuter des tests comme vous le souhaitez.

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

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

• Sécurisé : si votre site Web utilise le protocole 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. Comme tout le monde 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 multi-origines, 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éfinition d'une règle strict-origin-when-cross-origin policy

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 faire si strict-origin-when-cross-origin (ou plus stricte) ne convient pas à tous vos cas d'utilisation ?

Dans ce cas, adoptez une approche progressive : définissez une règle protectrice 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. Voir les détails.

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

script.js:

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

Que devez-vous prendre en compte d'autre ?

Votre règle 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 permettant d'identifier une personne ou des données sensibles, définissez une règle protectrice.

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 permettant d'identifier une personne. Assurez-vous donc de le traiter comme tel.

Les URL de provenance entrantes peuvent changer {referer-can-change}

L'utilisation de l'URL de provenance à partir de requêtes multi-origines 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 du Referer qu'avant.
• Les navigateurs utilisent de plus en plus la règle d'URL de provenance 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 multi-origines entrantes, si aucun site expéditeur n'a 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 tronquer les URL de provenance en origines dans les requêtes de sous-ressource multi-origines, 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 avoir une URL complète alors que vous souhaitez uniquement savoir si la requête est multi-origines.

Alternatives à Referer

Vous devrez peut-être envisager des alternatives si :

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

Pour définir des alternatives, analysez d'abord la partie de l'URL de provenance que vous utilisez.

Si vous n'avez besoin que de l'origine

• Si vous utilisez l'URL de provenance dans un script qui a un accès de premier niveau à la page, window.location.origin est une alternative.
• Si disponibles, les en-têtes tels que Origin et Sec-Fetch-Site vous donnent l'Origin ou décrivent si la requête est multi-origines, ce qui peut être 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 a un accès de premier niveau à la page, window.location.pathname peut fonctionner comme alternative. Extrayez uniquement la section de chemin d'accès de l'URL et transmettez-la en tant qu'argument, afin qu'aucune information potentiellement sensible dans les paramètres de l'URL ne soit transmise.

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 un type de configuration.
  • Avantage : plus explicite, plus respectueux de la confidentialité pour les utilisateurs de site-one.example, plus pérenne.
  • Inconvénient : potentiellement plus de travail de votre côté ou pour les utilisateurs de votre système.
• Vérifiez si le site qui émet les requêtes peut accepter de définir une règle d'URL de provenance no-referrer-when-downgrade 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 contrefaçon 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 un acteur malveillant 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.

Journalisation et débogage

Veillez à protéger les données personnelles ou sensibles des utilisateurs qui peuvent 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 à des fins de 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 les contrôles de sécurité.

Exemple :

• L'utilisateur clique sur le 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. S'il ne correspond à aucune entrée de la liste, payment-provider.example rejette la requête. S'il correspond, l'utilisateur peut passer à 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 contrôle de base contre certaines attaques. Toutefois, l'en-tête Referer lui-même n'est pas une base fiable pour un contrôle. 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 du Referer peut aider les fournisseurs de services de paiement à intercepter les attaquants naïfs qui n'ont pas défini de règle no-referrer. Si vous utilisez le Referer comme premier contrôle :

• Ne vous attendez pas à ce que le Referer soit toujours présent. S'il est présent, ne le comparez qu'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 vous attendant à ce qu'il n'y ait pas de Referer du tout ou à une valeur Referer qui ne soit que l'origine du site demandeur, vous évitez les erreurs qui pourraient résulter d'hypothèses sur la Referrer-Policy du marchand.
• Si le Referer est absent, ou s'il est présent et que votre contrôle d'origine Referer de base est réussi, vous pouvez passer à une autre méthode de validation plus fiable.

Pour valider les paiements de manière plus fiable, laissez le demandeur hacher les paramètres de la 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 du Referer lorsqu'un site marchand HTTP sans règle d'URL 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'aucun site Web n'a défini de règle. La modification apportée par Chrome à une nouvelle règle par défaut ne changera pas ce comportement.

Conclusion

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

Pour en savoir plus sur les différentes techniques de protection de vos utilisateurs, consultez notre collection Sécurité.

Ressources

• Comprendre les notions de "même site" et de "même origine"
• Un nouvel en-tête de sécurité : Referrer Policy (2017)
• Referrer-Policy sur MDN
• En-tête Referer : préoccupations concernant la confidentialité et la sécurité sur MDN
• Modification de Chrome : intention de Blink d'implémenter
• Modification de Chrome : intention de Blink de livrer
• 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 de l'URL de provenance : ce que font les différents navigateurs
• Spécification de la règle d'URL de provenance

Merci beaucoup à 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.