Cette page a été traduite par l'API Cloud Translation.

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 "même site" et "même origine".
L'en-tête Referer ne comporte pas de "R" en raison d'une faute d'orthographe 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 de provenance par défaut qui améliorent la confidentialité, afin de fournir une bonne solution de secours lorsqu'un site Web n'a aucune règle définie.
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 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 le changement en action.
Au-delà de la règle sur les URL de provenance, la façon dont les navigateurs traitent les URL de provenance peut changer. Gardez donc un œil dessus.

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 à partir de laquelle la requête a été effectuée. L'en-tête Referer-Policy définit les données disponibles 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. — *Referrer-Policy et Referer*

Si aucune règle n'est définie, la valeur par défaut du navigateur est utilisée. Les sites Web se réfèrent 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, la règle par défaut no-referrer-when-downgrade était largement répandue dans les navigateurs. Cependant, de nombreux navigateurs sont en train de passer à des paramètres par défaut qui renforcent 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'a été définie.

Qu'est-ce que cela change ?

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 d'origines multiples.

Cela permet d'éviter 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. — *L'URL de provenance (et document.referrer) est envoyée pour une requête d'origine croisée, en fonction de la règle.*

Exemple :

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

Avec no-referrer-when-downgrade : Referer : https://site-one.example/stuff/detail?tag=red.
Avec strict-origin-when-cross-origin : "Referer: https://site-one.example/."

Qu'est-ce qui ne change pas ?

Comme no-referrer-when-downgrade, strict-origin-when-cross-origin est secure : aucun référent (en-tête Referer et document.referrer) n'est présent lorsque la requête est effectuée à partir d'une origine HTTPS (sécurisée) vers une origine HTTP (non sécurisée). Ainsi, si votre site Web utilise 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. En effet, n'importe qui sur le réseau peut les voir, ce qui exposerait vos utilisateurs à des attaques de l'homme du milieu.
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/stuff/detail?tag=red vers https://site-one.example/… :

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

Quel est l'impact ?

D'après les discussions avec d'autres navigateurs et les propres tests de Chrome effectués 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é de l'URL de provenance complète seront probablement affectées par la réduction de la précision 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 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 de l'état de Chrome.

Comprendre et détecter le changement

Pour comprendre ce que les nouveaux paramètres par défaut impliquent concrètement, vous pouvez consulter cette démonstration.

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

Testez la modification et déterminez si elle aura un impact sur votre site.

Vous pouvez déjà tester ce changement à partir de Chrome 81 : accédez à chrome://flags/#reduced-referrer-granularity dans Chrome et activez le flag. Lorsque ce signalement 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 désormais vérifier le comportement de votre site Web et de votre backend.

Pour détecter l'impact, vous pouvez également vérifier si le code de votre site Web utilise le referrer, 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 ne plus fonctionner ou se comporter différemment si vous utilisez le referrer des requêtes provenant d'une autre origine vers votre site (plus précisément le chemin et/ou la chaîne de requête) ET que cette origine utilise la règle de referrer 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 d'autres solutions.

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

Utilisez d'autres techniques et en-têtes tels que Origin et Sec-fetch-Site pour votre protection CSRF, la journalisation et d'autres cas d'utilisation. Consultez Referer et Referrer-Policy : bonnes pratiques.
Si nécessaire, vous pouvez vous aligner sur une règle spécifique avec vos partenaires, à condition que cela soit transparent pour vos utilisateurs. Le contrôle des accès (lorsque le site de provenance est utilisé 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 sera 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 le referrer (consultez les valeurs par défaut des navigateurs et leur évolution dans Referer et Referrer-Policy : bonnes pratiques).

Mettre en œuvre des règles explicites et respectueuses de la confidentialité sur votre site

Quel Referer doit être envoyé dans les requêtes générées par votre site Web, c'est-à-dire quelle règle devez-vous définir pour votre site ?

Même en tenant compte de ce changement dans Chrome, il est conseillé de définir dès maintenant une règle explicite qui renforce la confidentialité, comme strict-origin-when-cross-origin ou une règle plus stricte.

Cela protège vos utilisateurs et permet à votre site Web de se comporter de manière plus prévisible dans les différents navigateurs. Il vous permet surtout de contrôler votre site, au lieu de le laisser dépendre des paramètres par défaut du navigateur.

Consultez "Referrer" et "Referrer-Policy" : bonnes pratiques pour savoir comment définir une règle.

À propos de Chrome Enterprise

La règle d'entreprise Chrome ForceLegacyDefaultReferrerPolicy est disponible pour les administrateurs informatiques qui souhaitent forcer l'ancienne règle par défaut concernant l'URL de provenance, à savoir no-referrer-when-downgrade, dans les environnements Enterprise. Cela leur laisse 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 d'expédition de Chrome ou tweetez vos questions à @maudnals.

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.