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

Maud Nalpas

Avant de commencer :

Si vous n'êtes pas sûr de la différence entre "site" et "origine", consultez Comprendre les notions de "même site" et de "même origine".
L'en-tête Referer comporte une faute d'orthographe (il manque un "r") en raison d'une erreur dans la spécification d'origine. 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 améliorent la confidentialité, afin de fournir une bonne solution de secours lorsqu'aucun règlement n'est défini pour un site Web.
Chrome prévoit d'activer progressivement strict-origin-when-cross-origin comme règle par défaut dans la version 85. Cela peut avoir un impact sur les cas d'utilisation qui s'appuient sur la valeur de l'URL de provenance d'une autre origine.
Il s'agit de la nouvelle valeur par défaut, mais les sites Web peuvent toujours choisir la règle de leur choix.
Pour tester la modification dans Chrome, activez le flag à l'adresse chrome://flags/#reduced-referrer-granularity. Vous pouvez également consulter cette démonstration pour voir la modification en action.
Au-delà de la règle d'URL de provenance, la façon dont les navigateurs gèrent les URL de provenance peut changer. Surveillez donc cette évolution.

Qu'est-ce qui change et pourquoi ?

Les requêtes HTTP peuvent inclure l'en-tête facultatif Referer header, 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 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 d'une requête provenant de votre site sont déterminées par l'en-tête Referrer-Policy que vous définissez.

Diagramme : Référent envoyé dans une requête. — *Règle d'URL de provenance et URL de provenance*

Si aucune règle n'est définie, la valeur par défaut du navigateur est utilisée. Les sites Web s'en remettent 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 largement répandue dans les navigateurs. Mais de nombreux navigateurs sont en train de passer à des valeurs par défaut qui améliorent 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'aura 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 plus de confidentialité. Avec cette règle, seule l' origine est envoyée dans l'en-tête Referer des requêtes multi-origines.

Cela empêche les fuites de données privées qui peuvent ê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.

Diagramme : URL de provenance envoyée en fonction de la règle, pour une requête d'origines multiples. — *URL de provenance envoyée (et document.referrer) pour une requête multi-origines, en fonction de la règle.*

Exemple :

Requête multi-origines, envoyée de https://site-one.example/stuff/detail?tag=red à https://site-two.example/… :

Avec no-referrer-when-downgrade : URL de provenance : https://site-one.example/stuff/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 effectuée d'une origine HTTPS (sécurisée) vers une origine HTTP (non sécurisée). Ainsi, si votre site Web utilise le protocole HTTPS (si ce n'est pas le cas, faites-en une priorité), les URL de votre site Web ne seront pas divulguées dans les requêtes non HTTPS, car toute personne sur le réseau peut les voir. Cela exposerait donc vos utilisateurs à des attaques de l'intercepteur.
Au sein de la même origine, la valeur de l'en-tête Referer correspond à l'URL complète.

Exemple : Requête de même origine, envoyée de https://site-one.example/stuff/detail?tag=red à https://site-one.example/… :

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

Quel est l'impact ?

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

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

Que devez-vous faire ?

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

Comprendre et détecter la modification

Pour comprendre les changements apportés par la nouvelle valeur par défaut dans la pratique, vous pouvez consulter cette démonstration.

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

Tester la modification et déterminer si elle aura un impact sur votre site

Vous pouvez déjà tester la modification à partir de Chrome 81 : accédez à chrome://flags/#reduced-referrer-granularity dans Chrome et activez le flag. Lorsque ce flag 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 : comment activer le flag chrome://flags/#reduced-referrer-granularity. — *Activation du flag*

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 la base de code de votre site Web utilise l'URL de provenance, soit via l'en-tête Referer des requêtes entrantes sur le serveur, soit à partir de document.referrer en JavaScript.

Certaines fonctionnalités de votre site peuvent être interrompues 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 que cette origine utilise la règle d'URL de provenance par défaut du navigateur (c'est-à-dire qu'aucune règle n'est définie).

Si cela a un impact sur votre site, envisagez des alternatives

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

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 URL de provenance et règle d'URL de provenance : bonnes pratiques.
Vous pouvez vous aligner sur les partenaires sur une règle spécifique si cela est nécessaire et transparent pour vos utilisateurs. Le contrôle des accès (lorsque l'URL de provenance est utilisée par les sites Web pour accorder un accès spécifique à leurs ressources à d'autres origines) peut être un cas de ce type, bien qu'avec la modification de Chrome, l'origine soit toujours partagée dans l'en-tête Referer (et dans document.referrer).

Notez que la plupart des navigateurs évoluent dans une direction similaire en ce qui concerne l'URL de provenance (consultez les valeurs par défaut des navigateurs et leur évolution dans URL de provenance et règle d'URL de provenance : bonnes pratiques.

Implémenter une règle explicite qui améliore la confidentialité sur l'ensemble de votre site

Quelle valeur Referer doit être envoyée dans les requêtes provenant de votre site Web, c'est-à-dire quelle règle devez-vous définir pour votre site ?

Même en tenant compte de la modification de Chrome, il est judicieux de définir dès maintenant une règle explicite qui améliore la confidentialité, comme strict-origin-when-cross-origin ou une règle plus stricte.

Cela protège vos utilisateurs et rend le comportement de votre site Web plus prévisible dans les différents navigateurs. La plupart du temps, cela vous donne le contrôle, au lieu de laisser votre site dépendre des valeurs par défaut du navigateur.

Consultez URL de provenance et règle d'URL de provenance : bonnes pratiques pour en savoir plus sur la définition d'une règle.

À 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 permet aux entreprises de disposer de plus de temps pour tester et mettre à jour leurs applications.

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

Envoyer des commentaires

Vous avez des commentaires à partager ou quelque chose à signaler ? Envoyez vos commentaires sur l'intention de Chrome de déployer cette fonctionnalité ou tweetez vos questions à @maudnals.

Merci beaucoup à tous les contributeurs et à tous ceux qui ont envoyé des commentaires, en particulier à Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck et Kayce Basques.