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 les mots clés "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 dans JavaScript et le DOM sont correctement orthographiés.

Résumé

Les navigateurs évoluent vers des règles par défaut liées aux URL de provenance, qui améliorent la confidentialité, afin de fournir une solution de remplacement appropriée 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 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 règle par défaut, mais les sites Web peuvent toujours choisir la règle de leur choix.
Pour tester la modification dans Chrome, activez l'indicateur sur chrome://flags/#reduced-referrer-granularity. Vous pouvez également regarder cette démonstration pour voir le changement en action.
Au-delà de la règle en matière d'URL de provenance, la façon dont les navigateurs gèrent les URL de provenance peut changer. Veillez donc à la surveiller.

Qu'est-ce qui change et pourquoi ?

Les requêtes HTTP peuvent inclure l'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 Referer-Policy définit les données qui sont 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 avez défini.

Schéma: référent envoyé dans une requête. — *Règles 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 appliquent souvent le paramètre 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 sur tous les navigateurs. Toutefois, de nombreux navigateurs sont à présent en train de passer à des paramètres par défaut plus favorables à la confidentialité.

Chrome prévoit de faire passer sa règle par défaut de no-referrer-when-downgrade à 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 ne s'appliquera qu'aux sites Web pour lesquels aucune règle n'est définie.

Qu'est-ce que cela implique ?

strict-origin-when-cross-origin renforce la confidentialité. 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-origines. — *URL de provenance envoyée (et document.referrer) pour une requête multi-origine, en fonction de la règle.*

Exemple :

Demande d'origine croisée, envoyée depuis https://site-one.example/stuff/detail?tag=red vers 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é: aucun référent (en-tête Referer et document.referrer) n'est présent lorsque la requête est effectuée depuis une origine HTTPS (sécurisée) vers une origine HTTP (non sécurisée). Ainsi, si votre site Web utilise le protocole HTTPS (sinon, donnez-lui la priorité), les URL de votre site ne seront pas divulguées dans les requêtes non HTTPS. En effet, tous les utilisateurs du réseau pourraient 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/stuff/detail?tag=red vers 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 les tests de Chrome exécutés dans Chrome 84, les problèmes de failles visibles par l'utilisateur devraient être limités.

La journalisation ou les analyses côté serveur qui s'appuient sur la disponibilité complète de l'URL de provenance risquent d'être affectées par la diminution 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 85 (juillet 2020 pour la version bêta, août 2020 pour la version stable). Consultez l'état dans la entrée "État de Chrome".

Comprendre et détecter le changement

Pour comprendre en pratique les modifications apportées par les nouvelles modifications par défaut, vous pouvez regarder 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.

Testez la modification et déterminez 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 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: Comment activer l'indicateur chrome://flags/#reduced-referrer-granularity. — *Activation de l'option*

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

Pour détecter l'impact, vous devez é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 à partir de document.referrer en JavaScript.

Certaines fonctionnalités de votre site peuvent ne pas fonctionner ou se comporter différemment si vous utilisez l'URL de provenance de 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 (c'est-à-dire si aucune règle n'est définie).

Si cela a un impact sur votre site, envisagez d'autres options

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 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 Règles relatives aux sites référents et aux sites référents: bonnes pratiques.
Vous pouvez vous mettre d'accord avec les partenaires sur un règlement 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 des sites Web pour accorder un accès spécifique à leurs ressources à d'autres origines) peut être un cas de ce type, bien qu'avec le changement 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 le même sens en ce qui concerne l'URL de provenance (pour en savoir plus sur les paramètres par défaut des navigateurs et leurs évolutions, consultez la section Règles relatives aux URL de provenance et aux règles de provenance: bonnes pratiques).

Appliquez sur l'ensemble de votre site des règles explicites visant à renforcer la confidentialité.

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 avec le changement de Chrome à l'esprit, nous vous recommandons de définir une règle explicite visant à améliorer la confidentialité, telle que strict-origin-when-cross-origin ou un niveau plus strict dès maintenant.

Cela protège les utilisateurs et rend le comportement de votre site Web plus prévisible sur tous les navigateurs. Dans la plupart des cas, cela vous donne le contrôle, plutôt que de laisser votre site dépendre des paramètres par défaut du navigateur.

Consultez la section Referrer and Referrer-Policy: best Practices (Bonnes pratiques relatives aux sites référents et aux référents) pour en savoir plus sur la définition d'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 d'URL de provenance par défaut no-referrer-when-downgrade dans les environnements d'entreprise. Les entreprises disposent ainsi de 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 quelque chose à signaler ? Faites-nous part de vos commentaires sur l'intention de lancer Chrome ou tweetez vos questions à l'adresse @maudnals.

Nous vous remercions vivement pour leurs contributions et leurs commentaires, en particulier Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck et Kayce Basques.