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 Referrer-Policy et utiliser le referrer dans les requêtes entrantes.

Résumé

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

Principes de base de l'en-tête "Referer" et "Referrer-Policy"

Les requêtes HTTP peuvent inclure un en-tête Referer facultatif, qui indique l'URL d'origine ou 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.

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.
• 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 Referer cross-origin, elle 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 personnellement l'utilisateur. La fuite silencieuse de ces informations entre les origines peut compromettre la confidentialité des utilisateurs du Web.

L'URL 6 est une URL de fonctionnalité. Si une personne autre que l'utilisateur prévu reçoit ce message, un acteur malveillant 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 le règlement, les données disponibles dans l'en-tête Referer (et document.referrer) peuvent être les suivantes :

• Aucune donnée (aucun en-tête Referer n'est présent)
• Seule l'origine
• 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 d'origine multiple ou d'origine identique, ou 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 avec des origines moins sécurisées, tout en conservant la richesse du referrer sur votre propre site.

Le tableau suivant montre comment les règles de référence restreignent les données d'URL disponibles dans l'en-tête "Referer" et document.referrer :

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

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

• 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 HTTP est moins sécurisé. En effet, pour ces règles, ce qui compte, c'est de savoir 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 du tout. 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

À partir d'octobre 2021

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

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

Il existe différentes façons de définir des stratégies 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 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 en vigueur 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. 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 demandes de sous-ressources de cette page suivent la règle strict-origin-when-cross-origin.

Comment afficher le règlement sur les URL de provenance ?

Le site securityheaders.com est utile 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 afficher la règle de référence 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é.

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

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

Pourquoi "explicitement" ?

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

• Les navigateurs ont des règles par défaut différentes. Si vous vous fiez à ces règles, votre site ne se comportera pas de manière prévisible sur tous les navigateurs.
• Les navigateurs adoptent des paramètres par défaut plus stricts, tels que strict-origin-when-cross-origin, et des mécanismes tels que le trimming de l'URL de provenance pour les requêtes multi-origines. En activant explicitement une règle améliorant 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 vous le souhaitez.

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

Vous avez besoin d'une stratégie sécurisée, respectueuse de la confidentialité et utile. La définition de "utile" dépend de ce que vous attendez du site référent :

• 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 les requêtes non HTTPS. Comme toute personne sur le réseau peut les voir, les fuites exposeraient vos utilisateurs à des attaques de l'homme du milieu. Les règles no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer et strict-origin résolvent ce problème.
• Confidentialité renforcée : pour une requête cross-origin, no-referrer-when-downgrade partage l'URL complète, ce qui peut poser des problèmes de confidentialité. strict-origin-when-cross-origin et strict-origin ne partagent que l'origine, tandis que no-referrer ne partage rien du tout. Il vous reste donc strict-origin-when-cross-origin, strict-origin et no-referrer comme options permettant d'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. 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 faire si strict-origin-when-cross-origin (ou une version plus stricte) ne convient 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 : stratégie 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 l'en-tête document.referrer ou Referer pour les requêtes intersites. En savoir plus

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

script.js :

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

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

Vos règles doivent 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 personnellement les utilisateurs ou des données sensibles, définissez une règle de protection.

Bonnes pratiques pour les demandes 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. Veillez donc à le traiter comme tel.

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

L'utilisation du referrer à partir des requêtes entrantes cross-origin 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 demande 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 la part 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 entrantes multi-origines, si le site expéditeur n'a défini aucune règle.
• Les navigateurs peuvent modifier la façon dont ils gèrent les 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-ressources d'origine croisée, 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 comporter une URL complète alors que vous souhaitez uniquement savoir si la requête est d'origine croisée.

Alternatives à Referer

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

• Une fonctionnalité essentielle de votre site utilise l'URL de provenance des requêtes entrantes d'origine croisée.
• Votre site ne reçoit plus la partie de l'URL de provenance dont il a besoin dans une requête cross-origin. 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 referrer que vous utilisez.

Si vous n'avez besoin que de l'origine

• Si vous utilisez le referrer dans un script qui a un accès de premier niveau à la page, window.location.origin est une alternative.
• Si des en-têtes tels que Origin et Sec-Fetch-Site sont disponibles, ils vous donnent le Origin ou décrivent si la requête est cross-origin, 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 le referrer.
• Si vous utilisez le referrer dans un script qui dispose d'un accès de premier niveau à 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. Ainsi, les informations potentiellement sensibles contenues dans les paramètres de l'URL ne sont 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 configuration.
  • Avantages : plus explicite, plus respectueux de la confidentialité pour les utilisateurs site-one.example, plus durable.
  • Inconvénient : cela peut potentiellement vous demander plus de travail ou en demander plus aux 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 la règle Referrer-Policy par élément ou par requête.
  • Inconvénients : confidentialité potentiellement moins respectée pour les utilisateurs site-one.example, compatibilité potentielle 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 le referrer en définissant une règle no-referrer, et un acteur malveillant pourrait même usurper le referrer.

Utilisez des jetons CSRF comme principale protection. Pour une protection renforcée, 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 s'il est disponible.

Journaliser et déboguer

Veillez à protéger les données utilisateur sensibles ou à caractère personnel qui peuvent se trouver dans 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 le referrer.

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 vérifie le Referer de cette requête par rapport à 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. Si c'est le cas, l'utilisateur peut passer à la transaction.

Bonnes pratiques pour les vérifications de sécurité du parcours de paiement

En tant que fournisseur de services de paiement, vous pouvez utiliser Referer comme vérification de base contre certaines attaques. Toutefois, l'en-tête Referer seul 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 un règlement no-referrer qui rend les informations Referer indisponibles pour le prestataire de paiement.

L'examen de Referer peut aider les fournisseurs de services de paiement à identifier 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. Si elle est présente, vérifiez-la uniquement par rapport aux données minimales qu'elle 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 aucune valeur Referer ou une valeur Referer qui n'est que l'origine du site demandeur, vous évitez les erreurs qui pourraient résulter d'hypothèses sur le Referrer-Policy du marchand.
• Si le Referer est absent, ou s'il est présent et que votre vérification de l'origine Referer de base réussit, vous pouvez passer à une autre méthode de validation plus fiable.

Pour valider les paiements de manière plus fiable, demandez au demandeur de hacher les paramètres de la requête avec une clé unique. Les fournisseurs de paiement peuvent ensuite calculer le même hachage de votre côté et n'accepter la demande que s'il correspond à votre calcul.

Que se passe-t-il pour le Referer lorsqu'un site marchand HTTP sans règle de référence redirige vers un fournisseur de paiement HTTPS ?

Aucun 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'aucun règlement n'est défini pour un site Web. Le passage de Chrome à une nouvelle règle par défaut ne changera pas ce comportement.

Conclusion

Une règle de référence protectrice est un excellent moyen de renforcer la confidentialité de vos utilisateurs.

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

Ressources

• Comprendre les concepts de "même site" et "même origine"
• 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 d'expédition de Blink
• Modification de Chrome : entrée d'état
• Article de blog sur les modifications apportées à Chrome 85 bêta
• Fil GitHub sur la suppression des informations sur le site référent : ce que font les différents navigateurs
• Spécification de la règle Referrer-Policy

Merci beaucoup à tous les relecteurs pour leurs contributions et leurs commentaires, en particulier à Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck et Kayce Basques.