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

Bonnes pratiques pour définir votre règle de provenance et utiliser l'URL de provenance dans les requêtes entrantes.

Maud Nalpas
Maud Nalpas

Résumé

  • Des fuites d'informations multi-origines inattendues nuisent à la confidentialité des internautes. Une politique protectrice d'URL de provenance peut vous aider.
  • Envisagez de définir une règle en matière d'URL de provenance sur strict-origin-when-cross-origin. Elle conserve une grande partie de l'utilité de l'URL de provenance, tout en limitant le risque de fuite de données entre origines multiples.
  • N'utilisez pas d'URL de provenance pour la protection contre la falsification des demandes intersites. Utilisez plutôt des jetons CSRF et d'autres en-têtes pour renforcer la sécurité.

Principes de base des règles relatives aux URL de provenance et aux sites référents

Les requêtes HTTP peuvent inclure l'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 mises à disposition dans l'en-tête Referer.

Dans l'exemple ci-dessous, 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.

Requête HTTP incluant un en-tête Referer.

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

  • Demandes de navigation, lorsqu'un utilisateur clique sur un lien
  • Les demandes de sous-ressources, lorsqu'un navigateur demande des images, des iFrames, des scripts et d'autres ressources dont la page a besoin.

Pour les navigations et les iFrames, ces données sont également accessibles via JavaScript à l'aide de document.referrer.

La valeur Referer peut être pertinente. Par exemple, un service d'analyse peut utiliser cette valeur pour déterminer que 50% des visiteurs de site-two.example proviennent de social-network.example.

Toutefois, lorsque l'URL complète, incluant le chemin d'accès et la chaîne de requête, est envoyée dans Referer entre toutes les origines, cela peut nuire à la confidentialité et présenter des risques de sécurité. Examinez ces URL:

URL avec des chemins associés à différents risques liés à la confidentialité et à la sécurité.

Les URL 1 à 5 contiennent des informations privées, parfois sensibles ou permettant d'identifier l'utilisateur. La divulgation silencieuse d'informations d'origine peut compromettre la confidentialité des internautes.

L'URL 6 est une URL de fonctionnalité. Vous ne voulez pas qu’elle tombe entre les mains de quelqu’un d’autre que l’utilisateur prévu. Si cela se produisait, un acteur malveillant pourrait pirater le compte de cet utilisateur.

Afin de limiter les données de provenance disponibles pour les requêtes provenant de votre site, vous pouvez définir une règle en matière d'URL de provenance.

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

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

  • Aucune donnée (aucun en-tête Referer n'est présent)
  • Uniquement l'origine
  • URL complète: origine, chemin d'accès et chaîne de requête
Données pouvant être contenues dans l'en-tête "Referer" et dans document.referrer.

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

Voici un aperçu montrant comment les règles en matière d'URL de provenance limitent les données d'URL disponibles à partir de l'en-tête du référent et de document.referrer:

Différentes règles d'URL de provenance et leur comportement en fonction du contexte de sécurité et d'origine multi-origine.

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

Points à noter :

  • Toutes les règles qui tiennent compte du schéma (HTTPS ou HTTP) (strict-origin, no-referrer-when-downgrade et strict-origin-when-cross-origin) traitent les requêtes provenant d'une origine HTTP vers une autre origine HTTP de la même manière que les requêtes provenant 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 est de savoir si une rétrogradation de sécurité a lieu, c'est-à-dire si la requête peut exposer les données d'une origine chiffrée à une origine non chiffrée. Une requête HTTP → HTTP n'est pas chiffrée depuis le début, il n'y a donc pas de retour à une version antérieure. Les requêtes HTTPS → HTTP, au contraire, entraînent un retour à une version antérieure.
  • Si une requête a la même origine, cela signifie que le schéma (HTTPS ou HTTP) est le même. Il n'y a donc pas de niveau de sécurité inférieur.

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

Données d'octobre 2021

Si aucune règle d'URL de provenance n'est définie, la règle par défaut du navigateur est utilisée.

Visiteur Referrer-Policy / Comportement par défaut
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 les moins restrictives concernant les URL de provenance no-referrer-when-downgrade, origin-when-cross-origin et unsafe-url sont ignorées pour les requêtes intersites. Cela signifie que l'URL de provenance est toujours tronquée pour les requêtes intersites, quelle que soit la règle du site Web.
Périphérie 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 spécificités. Pour en savoir plus, consultez la page Prévenir le suivi de la protection contre le suivi.

Configuration de vos règles en matière d'URL de provenance: bonnes pratiques

Il existe plusieurs façons de définir des règles en matière d'URL de provenance pour votre site:

Vous pouvez définir des règles différentes en fonction des pages, des demandes ou des éléments.

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

  1. Règle au niveau de l'élément
  2. Règles au niveau de la page
  3. Paramètre 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 sera demandée avec une règle no-referrer-when-downgrade, tandis que toutes les autres requêtes de sous-ressources de cette page suivront la règle strict-origin-when-cross-origin.

Comment consulter les règles en matière d'URL de provenance ?

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

Vous pouvez également utiliser les outils pour les développeurs de Chrome, Edge ou Firefox pour voir la règle d'URL 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'élément Referer envoyé.

Capture d&#39;écran du panneau &quot;Network&quot; (Réseau) des outils pour les développeurs Chrome, avec les paramètres Referer et Referrer-Policy.
Outils pour les développeurs Chrome : panneau Network (Réseau) avec une requête sélectionnée.

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

Résumé: définissez explicitement des règles qui améliorent la confidentialité, telles que strict-origin-when-cross-origin (ou des règles plus strictes).

Pourquoi "explicitement" ?

Si aucune règle d'URL de provenance n'est définie, la règle par défaut du navigateur est utilisée. En fait, les sites Web s'en tiennent souvent compte. Mais ce n'est pas idéal, car:

  • Les règles par défaut du navigateur sont no-referrer-when-downgrade, strict-origin-when-cross-origin ou plus strictes, selon le navigateur et le mode (privé/navigation privée). Le comportement de votre site Web ne sera donc 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 l'ajustement de l'URL de provenance pour les requêtes multi-origines. Activer explicitement des règles permettant de renforcer la confidentialité avant que les paramètres par défaut du navigateur ne soient modifiés vous permet de contrôler et d'exécuter des tests comme vous le souhaitez.

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

Vous avez besoin d'une règle sécurisée, qui améliore la confidentialité et qui soit utile. La signification de l'"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, définissez-le comme prioritaire), vous devez éviter que les URL de votre site Web soient divulguées dans les requêtes non HTTPS. Étant donné que n'importe quel utilisateur du réseau peut les voir, cela expose vos utilisateurs à des attaques de type "person-in-the-middle". Les règles no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer et strict-origin permettent de résoudre ce problème.
  • Amélioration de la confidentialité: pour une requête multi-origine, no-referrer-when-downgrade partage l'URL complète, ce qui n'améliore pas la confidentialité. strict-origin-when-cross-origin et strict-origin ne partagent que l'origine, et no-referrer ne partage rien. Vous disposez alors d'options strict-origin-when-cross-origin, strict-origin et no-referrer pour améliorer 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. Par conséquent, si vous en avez besoin, 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 la version 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 valeur plus stricte) ne convient pas à tous vos cas d'utilisation ?

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

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>

Notez que Safari/WebKit peut limiter document.referrer ou l'en-tête Referer pour les requêtes intersites. Afficher les détails

Exemple: stratégie au niveau de la requête

script.js:

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

Que devriez-vous envisager d'autre ?

Votre stratégie doit dépendre de votre site Web et de vos cas d'utilisation. Cela dépend de vous, de votre équipe et de votre entreprise. Si certaines URL contiennent des données sensibles ou permettant d'identifier l'utilisateur, définissez une règle de protection.

Utiliser l'URL de provenance à partir des requêtes entrantes: bonnes pratiques

Que faire si la fonctionnalité de votre site utilise l'URL de provenance des demandes entrantes ?

Protéger les données des utilisateurs

L'Referer peut contenir des données privées, personnelles ou d'identification. Veillez donc à les traiter comme telles.

N'oubliez pas que les Referer que vous recevez sont susceptibles de changer

L'utilisation de l'URL de provenance dans les requêtes multi-origines entrantes présente certaines limites:

  • Si vous n'avez aucun contrôle sur l'implémentation de l'émetteur de requêtes, vous ne pouvez pas faire d'hypothèses sur l'en-tête Referer (et document.referrer) que vous recevez. L'émetteur de requêtes peut décider à tout moment de passer à une règle no-referrer ou, plus généralement, à une règle plus stricte que celle qu'il utilisait auparavant. Vous recevrez donc moins de données via Referer qu'auparavant.
  • Les navigateurs utilisent de plus en plus l'attribut Referrer-Policy strict-origin-when-cross-origin par défaut. Cela signifie que vous pouvez désormais ne recevoir que l'origine (au lieu de l'URL de provenance complète) dans les requêtes multi-origines entrantes, si aucune règle n'est définie pour le site qui les envoie.
  • Les navigateurs peuvent modifier la façon dont ils gèrent Referer. Par exemple, à l'avenir, ils peuvent décider de toujours réduire les URL de provenance aux origines dans les requêtes de sous-ressources 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 une URL complète lorsque vous souhaitez seulement savoir si la requête est multi-origine.

Alternatives à Referer

Vous devrez peut-être envisager des alternatives si:

  • Une fonctionnalité essentielle de votre site utilise l'URL de provenance des demandes multi-origines entrantes.
  • et/ou si votre site ne reçoit plus la partie de l'URL de provenance dont il a besoin dans une requête multi-origine. Cela se produit lorsque l'émetteur de la requête a modifié 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 (https://site-one.example):

  • Si vous utilisez l'URL de provenance dans un script disposant d'un accès de niveau supérieur à la page, vous pouvez utiliser window.location.origin.
  • Le cas échéant, les en-têtes tels que Origin et Sec-Fetch-Site vous donnent le Origin ou indiquent si la requête est multi-origine, ce qui peut être exactement ce dont vous avez besoin.

Si vous avez besoin d'autres éléments de l'URL (chemin, 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 disposant d'un accès de premier niveau à la page, window.location.pathname peut être une alternative. Extrayez uniquement la section du chemin de l'URL et transmettez-la en tant qu'argument, de sorte que les informations potentiellement sensibles dans les paramètres d'URL ne soient pas transmises.

Si vous ne pouvez pas utiliser ces alternatives:

  • Vérifiez si vos systèmes peuvent être modifiés pour s'attendre à ce que l'émetteur de requêtes (site-one.example) définisse explicitement les informations dont vous avez besoin dans une configuration quelconque. Avantage: plus explicite, plus protégeant la confidentialité pour les utilisateurs de site-one.example et plus pérenne. Inconvénient: potentiellement plus de travail de votre part 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 de provenance par élément ou par requête de no-referrer-when-downgrade. Inconvénient: le respect de la confidentialité est potentiellement moins important pour les utilisateurs de site-one.example, et peut ne pas être compatible avec tous les navigateurs.

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

Notez qu'un émetteur de requêtes peut toujours décider de ne pas envoyer l'URL de provenance en définissant une règle no-referrer (et un acteur malveillant pourrait même usurper l'URL de provenance).

Utilisez les 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 pour les requêtes POST et CORS) et Sec-Fetch-Site (le cas échéant).

Journalisation

Assurez-vous de protéger les données personnelles ou sensibles des utilisateurs susceptibles de se trouver dans le Referer.

Si vous n'utilisez que l'origine, vérifiez si l'en-tête Origin peut être une alternative. Vous obtiendrez peut-être 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 vérifie le Referer de cette requête par rapport à une liste de valeurs Referer autorisées définies par les marchands. Si elle ne correspond à aucune entrée de la liste, payment-provider.example refuse la requête. Si tel est le cas, l'utilisateur peut effectuer la transaction.

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

En résumé: en tant que fournisseur de services de paiement, vous pouvez utiliser le Referer comme moyen de protection de base contre les attaques naïves, mais vous devez absolument disposer d'une autre méthode de validation plus fiable.

L'en-tête Referer seul ne constitue pas une base fiable pour un contrôle: le site à l'origine de la demande, qu'il s'agisse ou non d'un marchand légitime, peut définir une règle no-referrer qui rendra les informations Referer indisponibles pour le fournisseur de services de paiement. Toutefois, en tant que fournisseur de services de paiement, consulter Referer peut vous aider à repérer les pirates informatiques naïfs qui n'ont pas défini de règle no-referrer. Vous pouvez donc décider d'utiliser Referer comme première vérification de base. Dans ce cas:

  • Ne vous attendez pas à ce que Referer soit toujours présent. S'il est présent, ne comparez que l'élément de données qu'il inclura au minimum: l'origine. Lorsque vous définissez la liste des valeurs Referer autorisées, assurez-vous que seul l'origine est inclus, mais aucun chemin d'accès. Exemple: Les valeurs Referer autorisées pour online-shop.example doivent être online-shop.example, et non online-shop.example/cart/checkout. Pourquoi ? En vous attendant à aucune valeur Referer ou à une valeur Referer correspondant à l'origine du site Web à l'origine de la demande, vous évitez les erreurs inattendues, car vous n'émettez aucune hypothèse concernant le Referrer-Policy défini par votre marchand ni sur le comportement du navigateur s'il n'a défini aucune règle. Le site et le navigateur peuvent supprimer le Referer envoyé dans la requête entrante à l'origine uniquement ou ne pas envoyer le Referer.
  • Si le Referer est absent ou s'il est présent et que la vérification de l'origine Referer de base a réussi, vous pouvez passer à une autre méthode de validation plus fiable (voir ci-dessous).

Quelle méthode de validation peut être plus fiable ?

Une méthode de validation fiable consiste à laisser le demandeur hacher les paramètres de requête en même temps qu'une clé unique. En tant que fournisseur de services de paiement, vous pouvez ensuite calculer le même hachage de votre côté et accepter la requête uniquement 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 élément Referer n'est visible dans la requête envoyée au fournisseur de paiement HTTPS, car la plupart des navigateurs utilisent strict-origin-when-cross-origin ou no-referrer-when-downgrade par défaut lorsqu'aucune règle n'est définie pour un site Web. Notez également que la modification de la règle appliquée par Chrome ne modifiera pas ce comportement.

Conclusion

Une politique de protection en matière d'URL de provenance est un excellent moyen d'offrir une plus grande confidentialité à vos utilisateurs.

Pour en savoir plus sur les différentes techniques de protection des utilisateurs, consultez la collection Safe and secure (Sécurité et sécurité) de web.dev.

Nous vous remercions pour vos contributions et vos commentaires, en particulier Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck et Kayce Basques.

Ressources