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 à suivre pour définir votre règle de provenance et en utilisant l'URL de provenance dans les requêtes entrantes.

Résumé

• Une fuite inattendue d'informations multi-origines nuit aux utilisateurs Web confidentialité. A une politique de provenance de protection peut vous aider.
• Nous vous conseillons de définir une règle d'URL de provenance strict-origin-when-cross-origin. Il préserve en grande partie l'utilité de l'URL de provenance, tout en limitant le risque de les fuites de données multi-origines.
• N'utilisez pas d'URL de provenance pour la protection contre la falsification de requête intersites (CSRF). Utilisez Jetons CSRF et d'autres en-têtes comme niveau de sécurité supplémentaire.

Règles relatives aux URL de provenance et d'URL de provenance 101

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

Dans l'exemple suivant, l'en-tête Referer inclut l'URL complète du la page site-one à partir de laquelle la demande a été faite.

</ph>

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 une page a besoin.

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

Vous pouvez apprendre beaucoup des valeurs Referer. Par exemple, un service d'analyse pourrait les utiliser pour déterminer que 50% des visiteurs de site-two.example sont venus de social-network.example. Mais lorsque l'URL complète, y compris le chemin d'accès chaîne de requête, est envoyée dans le Referer à travers les origines, il peut mettre en danger l'utilisateur la confidentialité et engendrent des risques de sécurité:

</ph>

Les URL 1 à 5 contiennent des informations privées et parfois des informations sensibles ou des informations d'identification. Une fuite silencieuse d'une origine à l'autre peut compromettre des internautes confidentialité.

L'URL 6 est une URL de fonctionnalité. Si quelqu'un autre que l'utilisateur prévu, un acteur malveillant peut prendre le contrôle du compte de cet utilisateur.

Afin de limiter les données de provenance mises à disposition pour les demandes 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 diffèrent-elles ?

Vous pouvez sélectionner l'une des huit règles. En fonction de la politique, les données disponible dans l'en-tête Referer (et 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

</ph>

Certaines règles sont conçues pour se comporter différemment en fonction du contexte: requête multi-origines ou de même origine, que la destination de la requête soit la comme l'origine sécurisée, ou les deux. Cela permet de limiter la quantité d'informations partagées entre des origines ou des origines moins sécurisées, tout en conservant la richesse de l'URL de provenance sur votre 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 de l'URL de provenance et de document.referrer:

MDN fournit la liste complète des règles et des comportements exemples.

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

• 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 une autre origine HTTP de la même manière que les requêtes depuis une origine HTTPS vers une autre HTTPS est d'origine, même si HTTP est moins sécurisé. C'est parce que pour ces l'essentiel est de passer à un niveau de sécurité inférieur. que si la requête peut exposer des données d'une origine chiffrée à un emplacement non chiffré par exemple HTTPS → requêtes HTTP. Une requête HTTP → HTTP est complètement non chiffré, il n'y a donc pas de retour à une version antérieure.
• 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 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, le navigateur utilise sa règle par défaut.

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

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

• En tant qu'en-tête HTTP
• Dans votre HTML
• À partir de JavaScript à la demande

Vous pouvez définir des règles différentes pour chaque page, demande ou élément.

L'en-tête HTTP et l'élément Meta sont définis au niveau de la page. L'ordre de priorité pour Pour déterminer la stratégie applicable à un élément, procédez comme suit:

1. Règlement au niveau de l'élément
2. Règlement 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 est demandée avec une règle no-referrer-when-downgrade, et toutes les autres les demandes de sous-ressources de cette page suivent le strict-origin-when-cross-origin .

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

securityheaders.com permet de déterminer facilement qu'un site ou une page spécifique utilise.

Vous pouvez également utiliser les outils de développement dans Chrome, Edge ou Firefox pour voir stratégie 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 le Referer qui était envoyé.

</ph> <ph type="x-smartling-placeholder">

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

Nous vous recommandons vivement de définir explicitement des règles visant à améliorer la confidentialité, telles que strict-origin-when-cross-origin (ou un niveau plus strict).

Pourquoi "explicitement" ?

Si vous ne définissez pas de règle d'URL de provenance, la règle par défaut du navigateur est utilisée. En fait, les sites Web sont souvent applique la valeur par défaut du navigateur. Mais ce n'est pas idéal pour les raisons suivantes:

• Les règles par défaut varient d'un navigateur à l'autre. Par conséquent, si vous utilisez des navigateurs par défaut, le comportement de votre site sur différents navigateurs n'est pas prévisible.
• 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. Activation explicite de règles améliorant la confidentialité avant la modification des paramètres par défaut du navigateur vous donne le contrôle et vous aide à exécuter des tests comme bon vous semble.

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

Vous avez besoin de règles sûres, utiles et qui améliorent la confidentialité. Qu'est-ce qu'« utile » dépend de ce que vous souhaitez de l'URL de provenance:

• Sécurité: si votre site Web utilise HTTPS (si ce n'est pas le cas, créez un ), vous ne souhaitez pas que les URL de votre site Web apparaissent aux requêtes autres que HTTPS. Puisque n'importe quel utilisateur du réseau peut les voir, les fuites exposer vos utilisateurs à des attaques de type « person-in-the-middle ». Règles no-referrer-when-downgrade, strict-origin-when-cross-origin, no-referrer et strict-origin résolvent ce problème.
• Améliorer la confidentialité: pour une requête d'origine croisée, 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 aucune information. Cela vous laisse strict-origin-when-cross-origin, strict-origin et no-referrer en tant que 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 le choix judicieux.

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

index.html :

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

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 un paramètre plus strict) ne prend pas en charge tous vos cas d'utilisation ?

Dans ce cas, adoptez une approche progressive: définissez une stratégie de protection telle que strict-origin-when-cross-origin pour votre site Web et, si nécessaire, pour des demandes 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. Afficher les détails

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, votre équipe et votre entreprise. Si certaines URL contiennent des données personnelles ou sensibles, définir une politique de protection.

Bonnes pratiques pour les requêtes entrantes

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

Protéger les utilisateurs données

Le Referer peut contenir des données privées, personnelles ou d'identification. Assurez-vous donc vous la traitez comme telle.

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

L'utilisation de l'URL de provenance des requêtes multi-origines entrantes présente quelques limites:

• Si vous n'avez aucun contrôle sur l'implémentation de l'émetteur de requêtes, vous ne pouvez pas faire des hypothèses sur l'en-tête Referer (et document.referrer) que vous recevoir. L'émetteur de requêtes peut décider de passer à une règle no-referrer. à tout moment ou, plus généralement, selon des règles plus strictes utilisé précédemment. Vous recevez donc moins de données de Referer qu'auparavant.
• Les navigateurs utilisent de plus en plus la règle de provenance strict-origin-when-cross-origin par défaut. Il se peut donc que vous ne receviez que l'origine, au lieu de une URL de provenance complète dans les requêtes multi-origines entrantes, si le site expéditeur aucune règle n'est définie.
• Les navigateurs peuvent modifier la façon dont ils gèrent Referer. Par exemple, certains navigateurs les développeurs peuvent décider de toujours réduire les URL de provenance aux origines multi-origines. les demandes de sous-ressources, afin de protéger la confidentialité des utilisateurs.
• L'en-tête Referer (et document.referrer) peuvent contenir plus de données que dont vous avez besoin. Par exemple, il peut avoir une URL complète alors que vous voulez seulement savoir si la requête est multi-origines.

Alternatives à Referer

Vous devrez peut-être envisager d'autres options dans les cas suivants:

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

Pour définir d'autres options, commencez par analyser 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 disposant d'un accès de premier niveau à la page, window.location.origin est une alternative.
• Le cas échéant, des en-têtes tels que Origin et Sec-Fetch-Site vous fournir le Origin ou indiquer si la requête est multi-origines, pourrait ê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 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 fonctionner comme une alternative. Extraire uniquement le chemin d'accès de l'URL et le transmettre en tant qu'argument, de sorte que toute les informations contenues dans les paramètres d'URL ne sont pas transmises.

Si vous ne pouvez pas utiliser ces alternatives:

• Vérifiez si vous pouvez modifier vos systèmes pour qu'ils s'attendent à l'émetteur de requêtes (par exemple, site-one.example) pour définir explicitement les informations dont vous avez besoin dans une configuration.
  • Avantage: contenu plus explicite et plus respectueux de la confidentialité pour les utilisateurs de site-one.example plus pérennes.
  • Inconvénient: davantage de travail de votre côté ou pour les utilisateurs de votre système.
• Vérifiez si le site qui émet les requêtes accepte de définir un "Referrer-Policy" par élément ou par requête de no-referrer-when-downgrade.
  • Inconvénient: la protection de la confidentialité est potentiellement moins importante pour les utilisateurs de site-one.example, potentiellement incompatible avec tous les navigateurs.

Protection CSRF (Cross-Site Request Forgery)

Un émetteur de requêtes peut toujours décider de ne pas envoyer l'URL de provenance en définissant un no-referrer, et un individu malveillant pourrait même simuler l'URL de provenance.

Utiliser des jetons CSRF comme protection principale. Pour plus de protection, utilisez SameSite au lieu de Referer, utilisez des en-têtes tels que Origin (disponible pour les requêtes POST et CORS) et Sec-Fetch-Site si elles sont disponibles.

Consigner et déboguer

Veillez à protéger les utilisateurs sensibles ou à caractère personnel qui peuvent se trouver Referer

Si vous n'utilisez que l'origine, vérifiez si vous pouvez utiliser Origin en tant que une alternative. Cela pourrait vous donner 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 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 le transaction.
• payment-provider.example compare le Referer de cette requête à une liste des valeurs Referer autorisées configurées par les marchands. Si aucune correspondance entrée dans la liste, payment-provider.example rejette la requête. Si c'est le cas l'utilisateur peut procéder à la transaction.

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

En tant que fournisseur de services de paiement, vous pouvez utiliser Referer comme moyen de contrôle de base pour certaines contre les attaques. Cependant, l'en-tête Referer en lui-même ne constitue pas une base fiable pour un chèque. Le site à l'origine de la demande, qu'il s'agisse d'un marchand légitime ou non, peut définir un Règle no-referrer qui empêche l'accès aux informations Referer un fournisseur de services de paiement.

Examiner le Referer peut aider les fournisseurs de services de paiement à détecter les pirates informatiques simplistes qui n'a 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 par rapport uniquement aux données minimales qu'il peut inclure, c'est-à-dire 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 anticipant soit aucune valeur Referer, soit une valeur Referer correspondant uniquement à la valeur l'origine du site, vous évitez les erreurs qui pourraient provenir de concernant les Referrer-Policy du marchand.
• Si l'élément Referer est absent, ou s'il est présent et que votre origine Referer de base est présente si la vérification est réussie, vous pouvez passer à une autre, plus fiable, .

Pour une validation plus fiable des paiements, autorisez 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'acceptez la demande que si elle correspond à votre calcul.

Qu'advient-il du Referer lorsqu'un site marchand HTTP sans URL de provenance ? le règlement redirige-t-il vers un fournisseur de services de paiement HTTPS ?

Aucun Referer n'est visible dans la requête envoyé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'aucune règle n'est définie pour un site Web. Nouvelle règle par défaut appliquée à Chrome ne changera pas ce comportement.

Conclusion

Une politique de protection des URL de provenance 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 Collecte sécurisée

Ressources

• Comprendre un même site et "same-origin"
• Nouvel en-tête de sécurité: stratégie d'URL de provenance (2017).
• Referrer-Policy activée MDN
• En-tête du référent: Préoccupations concernant la confidentialité et la sécurité sur MDN
• Modification de Chrome: Faire clignoter l'intent vers implémenter
• Modification de Chrome: Faire clignoter l'intent vers vaisseau
• Modification de Chrome: saisie de l'état
• Modification de Chrome: version bêta 85 blogpost
• URL de provenance pour la suppression du fil de discussion GitHub: quels navigateurs à faire
• Spécification de la règle de provenance

Merci beaucoup pour leurs contributions et leurs commentaires à l'ensemble des contributeurs, en particulier à Kaustubha Govind. David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck et Kayce Basques.