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é
- Des fuites d'informations multi-origines inattendues nuisent à la confidentialité des internautes. Une stratégie de protection en matière 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 préserve 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 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 mises à disposition 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.
- 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, vous pouvez également accéder à ces données avec JavaScript à l'aide de document.referrer
.
Les valeurs Referer
vous permettent d'apprendre beaucoup de choses. 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
sur toutes les origines, cela peut compromettre la confidentialité des utilisateurs et engendrer des risques de sécurité:
Les URL 1 à 5 contiennent des informations privées, et parfois des informations sensibles ou permettant d'identifier l'utilisateur. Une fuite silencieuse sur différentes origines peut compromettre la confidentialité des internautes.
L'URL 6 est une URL de fonctionnalité. Si une personne autre que l'utilisateur prévu reçoit cette information, un acteur malveillant peut prendre le contrôle du 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
Certaines règles sont conçues pour se comporter différemment selon le contexte : requête multi-origine ou requête de même origine, que la destination de la requête soit aussi sécurisée que l'origine, ou les deux. Cela permet de limiter la quantité d'informations partagées entre les origines ou les 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 en matière d'URL de provenance limitent les données d'URL disponibles à partir de l'en-tête du site référent et de document.referrer
:
Champ d'application des règles | Nom de la stratégie | URL de provenance: aucune donnée | URL de provenance: origine uniquement | URL de provenance: URL complète |
---|---|---|---|---|
Ne prend pas en compte le contexte de la requête | no-referrer |
coche | ||
origin |
coche | |||
unsafe-url |
coche | |||
Renforcement de la sécurité | strict-origin |
Requête de HTTPS vers HTTP | Requête de HTTPS vers HTTPS ou de HTTP vers HTTP |
|
no-referrer-when-downgrade |
Requête de HTTPS vers HTTP | Requête de HTTPS vers HTTPS ou de HTTP vers HTTP |
||
Respect de la confidentialité | origin-when-cross-origin |
Requête multi-origine | Requête d'origine identique | |
same-origin |
Requête multi-origine | Requête d'origine identique | ||
Priorité à la confidentialité et à la sécurité | strict-origin-when-cross-origin |
Requête de HTTPS vers HTTP | Requête multi-origine HTTPS vers HTTPS ou HTTP vers HTTP |
Requête d'origine identique |
MDN fournit une liste complète de règles et d'exemples de comportements.
Voici quelques points à prendre en compte lors de la configuration d'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
etstrict-origin-when-cross-origin
) traitent les requêtes d'une origine HTTP à 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 importe est de savoir si une rétrogradation de sécurité a lieu ou non, c'est-à-dire si la requête peut exposer les 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 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 rétrogradation de sécurité.
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.
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 en matière d'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 différences spécifiques. Pour en savoir plus, consultez la page
Prévenir le suivi de la protection contre le suivi.
|
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-tête HTTP
- Dans votre fichier HTML
- À partir de JavaScript, à la demande
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é permettant de déterminer la stratégie applicable d'un élément est le suivant:
- Règle au niveau de l'élément
- Règles au niveau de la page
- 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 requêtes de sous-ressources de cette page respectent 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 règle utilisée par un site ou une page spécifiques.
Vous pouvez également utiliser les outils pour les développeurs dans 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 le Referer
envoyé.
Quelle règle devez-vous définir pour votre site Web ?
Nous vous recommandons vivement de définir explicitement des règles améliorant la confidentialité, comme 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 est utilisée. En fait, les sites Web s'en servent souvent. Mais ce n'est pas idéal, car:
- Les règles par défaut varient d'un navigateur à l'autre. Par conséquent, si vous utilisez ces valeurs, votre site ne se comportera pas de manière 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 améliorant la confidentialité avant la modification des paramètres par défaut du navigateur 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 de règles sécurisées, utiles et axées sur la confidentialité. La signification d'"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, les fuites exposent vos utilisateurs à des attaques de type "person-in-the-middle". Les règles
no-referrer-when-downgrade
,strict-origin-when-cross-origin
,no-referrer
etstrict-origin
résolvent 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 peut causer des problèmes de confidentialité.strict-origin-when-cross-origin
etstrict-origin
ne partagent que l'origine, etno-referrer
ne partage aucunement. Vous disposez alors d'optionsstrict-origin-when-cross-origin
,strict-origin
etno-referrer
pour améliorer la confidentialité. - Utile:
no-referrer
etstrict-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, il est préférable d'utiliserstrict-origin-when-cross-origin
.
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 ou les é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'});
Que devriez-vous envisager d'autre ?
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 sensibles ou permettant d'identifier l'utilisateur, définissez une stratégie de protection.
Bonnes pratiques pour les requêtes entrantes
Voici quelques consignes sur la procédure à 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 à les traiter comme telles.
Les nouveaux parrains peuvent changer {referer-can-change}
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
(etdocument.referrer
) que vous recevez. L'émetteur de requêtes peut décider de passer à une règleno-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 deReferer
qu'auparavant. - Les navigateurs utilisent de plus en plus l'objet Referrer-Policy
strict-origin-when-cross-origin
par défaut. Cela signifie que vous pouvez désormais ne recevoir que l'origine, et non une URL de provenance complète, dans les requêtes multi-origines entrantes, si aucune règle n'est définie pour le site d'envoi. - Les navigateurs peuvent modifier leur façon de gérer
Referer
. Par exemple, certains développeurs de navigateurs 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
(etdocument.referrer
) peuvent contenir plus de données que nécessaire. Par exemple, elle peut avoir 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 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-origine. Cela se produit lorsque l'émetteur de la requête modifie ses règles, ou lorsqu'il n'a défini aucune règle 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 de l'URL de provenance que vous utilisez.
Si vous avez uniquement besoin de l'origine
- 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, des en-têtes tels que
Origin
etSec-Fetch-Site
vous donnent leOrigin
ou indiquent si la requête est multi-origine, ce qui peut correspondre 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 niveau supérieur à la page,
window.location.pathname
peut fonctionner à la place. Extrayez uniquement la section du chemin de l'URL et transmettez-la en tant qu'argument, de sorte que les informations potentiellement sensibles présentes dans les 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 requêtes (par exemple,
site-one.example
) définisse explicitement les informations dont vous avez besoin dans une configuration.- Avantage: plus explicite, plus respectueux de la confidentialité pour les utilisateurs de
site-one.example
et plus pérenne. - Inconvénient: potentiellement plus de travail de votre part ou des utilisateurs de votre système.
- Avantage: plus explicite, plus respectueux de la confidentialité pour les utilisateurs de
- Vérifiez si le site qui émet les requêtes peut accepter de définir une règle de référent par élément ou par requête de
no-referrer-when-downgrade
.- Inconvénient: le respect de la vie privée est potentiellement moins important pour les utilisateurs de
site-one.example
, et cette fonctionnalité n'est potentiellement pas compatible avec tous les navigateurs.
- Inconvénient: le respect de la vie privée est potentiellement moins important pour les utilisateurs de
Protection contre la falsification des requêtes intersites (CSRF)
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 peut 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
s'il est disponible.
Consigner et déboguer
Veillez à protéger les données sensibles ou à caractère personnel des utilisateurs susceptibles de se trouver dans le Referer
.
Si vous n'utilisez que l'origine, vérifiez si vous pouvez utiliser l'en-tête Origin
à la place. 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 verspayment-provider.example
pour gérer la transaction.payment-provider.example
vérifie leReferer
de cette requête par rapport à une liste de valeursReferer
autorisées définies par les marchands. Si elle ne correspond à aucune entrée de la liste,payment-provider.example
rejette 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 tant que fournisseur de services de paiement, vous pouvez utiliser Referer
comme méthode de base contre certaines attaques. Cependant, l'en-tête Referer
en soi n'est pas une base fiable pour une vérification. Le site à l'origine de la demande, 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.
Examiner 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, comparez-le uniquement 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. - Par exemple, les valeurs
Referer
autorisées pouronline-shop.example
doivent êtreonline-shop.example
, et nononline-shop.example/cart/checkout
. En ne vous attendant à aucune valeurReferer
ou à une valeurReferer
qui ne correspond qu'à l'origine du site à l'origine de la demande, vous évitez les erreurs dues à des hypothèses concernant leReferrer-Policy
du marchand.
- Lorsque vous définissez la liste des valeurs
- Si le
Referer
est absent ou s'il est présent et que la vérification de l'origineReferer
de base aboutit, vous pouvez passer à une autre méthode de validation plus fiable.
Pour une vérification plus fiable des paiements, 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 du Referer
lorsqu'un site marchand HTTP sans règle en matière d'URL de provenance redirige vers un fournisseur de services de paiement HTTPS ?
Aucun élément Referer
n'est visible dans la requête adressé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.
La nouvelle règle par défaut de Chrome ne changera 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 notre collection Sécurité et protection.
Ressources
- Comprendre les termes "same-site" et "same-origin"
- Nouvel en-tête de sécurité: stratégie d'URL de provenance (2017)
- Referrer-Policy on MN (Règle sur les sites référents)
- En-tête du référent: préoccupations concernant la confidentialité et la sécurité sur le MN
- Modification de Chrome: intent de clignotement à implémenter
- Modification de Chrome: clignotement de l'intent pour expédier
- Modification de Chrome: saisie de l'état
- Modification de Chrome: article de blog version 85 sur la version bêta
- URL de provenance du thread GitHub: ce que font les différents navigateurs
- Spécification des règles de référent
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.