Nouvelle règle de provenance par défaut pour Chrome : strict-origin-when-cross-origin

Maud Nalpas
Maud Nalpas

Avant de commencer:

  • Si vous avez un doute sur la différence entre "site " et"origine ", consultez l'article Comprendre les termes "same-site" et "same-origin".
  • Il manque un R dans l'en-tête Referer en raison d'une faute d'orthographe d'origine dans la spécification. L'en-tête Referrer-Policy et referrer en JavaScript et dans le DOM sont correctement orthographiés.

Résumé

  • Les navigateurs évoluent vers des règles d'URL de provenance par défaut qui renforcent la confidentialité afin de fournir une bonne solution de remplacement lorsqu'aucune règle n'est définie pour un site Web.
  • Chrome prévoit d'activer progressivement strict-origin-when-cross-origin comme règle par défaut à partir de la version 85. Cela peut affecter les cas d'utilisation qui se basent sur la valeur de l'URL de provenance d'une autre origine.
  • Il s'agit de la nouvelle règle par défaut, mais les sites Web peuvent toujours choisir une règle de leur choix.
  • Pour tester la modification dans Chrome, activez l'indicateur sur chrome://flags/#reduced-referrer-granularity. Vous pouvez également consulter cette démonstration pour voir ce changement en action.
  • Au-delà des règles relatives aux URL de provenance, la manière dont les navigateurs gèrent les URL de provenance peut changer. Gardez donc un œil sur la situation.

Qu'est-ce qui change et pourquoi ?

Les requêtes HTTP peuvent inclure l'en-tête Referer facultatif, qui indique l'URL d'origine ou de la page Web d'où provient la requête. L'en-tête Referer-Policy définit les données mises à disposition dans l'en-tête Referer, ainsi que pour la navigation et les iFrames dans le document.referrer de la destination.

Les informations exactes envoyées dans l'en-tête Referer dans une requête provenant de votre site sont déterminées par l'en-tête Referrer-Policy que vous définissez.

Schéma: URL de provenance envoyée dans une requête.
Referrer-Policy and Referer

Si aucune règle n'est définie, la valeur par défaut du navigateur est utilisée. Les sites Web appliquent souvent la valeur par défaut du navigateur.

Pour les navigations et les iFrames, les données présentes dans l'en-tête Referer sont également accessibles via JavaScript à l'aide de document.referrer.

Jusqu'à récemment, no-referrer-when-downgrade était une règle par défaut généralisée dans tous les navigateurs. Toutefois, de nombreux navigateurs sont en train de passer à des paramètres par défaut davantage respectueux de la confidentialité.

Chrome prévoit de remplacer sa règle par défaut no-referrer-when-downgrade par strict-origin-when-cross-origin, à partir de la version 85.

Cela signifie que si aucune règle n'est définie pour votre site Web, Chrome utilisera strict-origin-when-cross-origin par défaut. Notez que vous pouvez toujours définir la règle de votre choix. Cette modification n'a d'effet que sur les sites Web pour lesquels aucune règle n'est définie.

Qu'est-ce que cela signifie ?

strict-origin-when-cross-origin offre une confidentialité renforcée. Avec cette règle, seule l'origine est envoyée dans l'en-tête Referer des requêtes multi-origines.

Cela permet d'éviter les fuites de données privées qui pourraient être accessibles à partir d'autres parties de l'URL complète, telles que le chemin d'accès et la chaîne de requête.

Schéma: URL de provenance envoyée en fonction de la règle, pour une requête multi-origine.
Le référent envoyé (et document.referrer) pour une requête multi-origine, en fonction de la règle

Exemple :

Requête multi-origine, envoyée depuis https://site-one.example/contenu/detail?tag=red vers https://site-two.example/... :

  • Avec no-referrer-when-downgrade: URL de provenance: https://site-one.example/contenu/detail?tag=red.
  • Avec strict-origin-when-cross-origin: URL de provenance: https://site-one.example/.

Qu'est-ce qui ne change pas ?

  • Comme no-referrer-when-downgrade, strict-origin-when-cross-origin est sécurisé: aucune URL de provenance (en-tête Referer et document.referrer) n'est présente lorsque la requête est envoyée depuis une origine HTTPS (sécurisée) vers une origine HTTP (non sécurisée). De cette manière, si votre site Web utilise le protocole HTTPS (sinon, définissez-le comme prioritaire), ses URL ne seront pas diffusées dans des requêtes qui ne sont pas de type HTTPS. En effet, n'importe quel utilisateur sur le réseau peut les voir, ce qui expose vos utilisateurs à des attaques MITM ("man in the middle").
  • Dans la même origine, la valeur de l'en-tête Referer correspond à l'URL complète.

Par exemple : requête de même origine, envoyée depuis https://site-one.example/contenu/detail?tag=red vers https://site-one.example/... :

  • Avec strict-origin-when-cross-origin: URL de provenance: https://site-one.example/contenu/detail?tag=red

Quel est l'impact ?

D'après les discussions avec d'autres navigateurs et la propre exécution de Chrome dans Chrome 84, les problèmes visibles par les utilisateurs devraient être limités.

La journalisation ou les analyses côté serveur qui reposent sur la disponibilité complète de l'URL de provenance sont susceptibles d'être affectées par une précision réduite de ces informations.

Que devez-vous faire ?

Chrome prévoit de commencer à déployer la nouvelle règle par défaut en matière d'URL de provenance à compter de 85 (juillet 2020 pour la version bêta et août 2020 pour la version stable). Consultez l'état dans la entrée d'état de Chrome.

Comprendre et détecter le changement

Pour comprendre quelles modifications ont été apportées par défaut dans la pratique, vous pouvez consulter cette démonstration.

Vous pouvez également utiliser cette démonstration pour savoir quelle règle est appliquée dans l'instance Chrome que vous exécutez.

Testez la modification et déterminez son impact sur votre site.

Vous pouvez déjà essayer la modification à partir de Chrome 81: accédez à chrome://flags/#reduced-referrer-granularity dans Chrome et activez l'indicateur. Lorsque cet indicateur est activé, tous les sites Web sans règle utilisent la nouvelle valeur par défaut strict-origin-when-cross-origin.

Capture d'écran de Chrome: activer l'indicateur chrome://flags/#reduced-referrer-granularity
Activation de l'indicateur.

Vous pouvez maintenant vérifier le comportement de votre site Web et de votre backend.

Pour détecter l'impact, vous pouvez également vérifier si le codebase de votre site Web utilise l'URL de provenance, soit via l'en-tête Referer des requêtes entrantes sur le serveur, soit via document.referrer dans JavaScript.

Certaines fonctionnalités de votre site peuvent ne plus fonctionner ou se comporter différemment si vous utilisez l'URL de provenance des requêtes provenant d'une autre origine vers votre site (plus précisément, le chemin d'accès et/ou la chaîne de requête) ET si cette origine utilise la règle par défaut du navigateur en matière d'URL de provenance (aucune règle n'est définie).

Si cela a une incidence sur votre site, envisagez d'autres solutions.

Si vous utilisez l'URL de provenance pour accéder au chemin d'accès complet ou à la chaîne de requête des requêtes vers votre site, plusieurs options s'offrent à vous:

  • Utilisez d'autres techniques et en-têtes tels que Origin et Sec-fetch-Site pour la protection CSRF, la journalisation et d'autres cas d'utilisation. Consultez le document Referer and Referrer-Policy: best practices (Règles relatives aux sites référents et aux sites référents).
  • Si nécessaire et de façon transparente pour vos utilisateurs, vous pouvez définir des règles spécifiques avec vos partenaires. Le contrôle des accès (lorsque l'URL de provenance est utilisée par des sites Web pour accorder à d'autres origines un accès spécifique à leurs ressources) peut se produire. Toutefois, en raison de la modification de Chrome, l'origine sera toujours partagée dans l'en-tête Referer (et dans document.referrer).

Notez que la plupart des navigateurs évoluent dans la même direction en ce qui concerne l'URL de provenance (consultez les paramètres par défaut des navigateurs et leur évolution dans Referer and Referrer-Policy: best practices).

instaurer sur l'ensemble de votre site des règles explicites axées sur la confidentialité ;

Quelle valeur Referer doit être envoyée dans les requêtes provenant de votre site Web : quelles règles devez-vous définir pour votre site ?

Même si Chrome a changé d'esprit, nous vous recommandons de définir dès maintenant des règles explicites améliorant la confidentialité, comme strict-origin-when-cross-origin ou plus strictes.

Cela permet de protéger vos utilisateurs et de rendre votre site Web plus prévisible d'un navigateur à l'autre. Globalement, cela vous donne le contrôle, au lieu de laisser votre site dépendre des paramètres par défaut du navigateur.

Pour en savoir plus sur la définition d'une règle, consultez Referrer and Referrer-Policy: best practices (Règles de parrainage et bonnes pratiques).

À propos de Chrome Enterprise

La règle Chrome Enterprise ForceLegacyDefaultReferrerPolicy est disponible pour les administrateurs informatiques qui souhaitent forcer l'ancienne règle d'URL de provenance par défaut no-referrer-when-downgrade dans les environnements d'entreprise. Cela laisse aux entreprises plus de temps pour tester et mettre à jour leurs applications.

Cette règle sera supprimée dans Chrome 88.

Envoyer des commentaires

Avez-vous des commentaires à partager ou des informations à signaler ? Faites-nous part de vos commentaires sur l'intention de lancement de Chrome ou envoyez vos questions par tweet à @maudnals.

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

Ressources