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 ne savez pas quelle est la différence entre "site" et "origine", consultez Comprendre les termes "same-site" et "same-origin".
L'en-tête Referer manque une lettre R, en raison d'une faute de frappe initiale dans les spécifications. 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 par défaut en matière d'URL de provenance qui renforcent la confidentialité, afin de fournir un bon plan de secours 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 valeur 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 à l'emplacement chrome://flags/#reduced-referrer-granularity. Vous pouvez également consulter cette démo pour voir le changement en action.
En plus de la règle sur les sites référents, la façon dont les navigateurs gèrent les sites référents peut changer. Tenez-en compte.

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 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.

Schéma: Référent envoyé dans une requête. — *Referrer-Policy et Referer.*

Lorsque aucune règle n'est définie, le comportement par défaut du navigateur est utilisé. Les sites Web reposent souvent sur les paramètres par défaut du navigateur.

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

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

Chrome prévoit de remplacer no-referrer-when-downgrade par strict-origin-when-cross-origin comme règle par défaut, à 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 une règle de votre choix. Ce changement n'aura d'incidence que sur les sites Web pour lesquels aucune règle n'est définie.

Que signifie ce changement ?

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 évite les fuites de données privées pouvant être accessibles à partir d'autres parties de l'URL complète, telles que le chemin et la chaîne de requête.

Schéma: URL de provenance envoyée en fonction de la règle pour une requête inter-origine. — *URL de provenance envoyée (et document.referrer) pour une requête inter-origine, 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 sécurisé: 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 (sinon, faites-en une priorité), ses URL ne seront pas divulguées dans les requêtes non HTTPS, car n'importe qui sur le réseau peut les voir. Cela exposerait vos utilisateurs à des attaques de l'intercepteur.
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 tests effectués par Chrome dans Chrome 84, les erreurs visibles par l'utilisateur devraient être limitées.

La journalisation ou l'analyse côté serveur qui reposent sur la disponibilité de l'URL complète du site référent sont susceptibles d'être affectées par une granularité 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 dans la version 85 (juillet 2020 pour la version bêta, août 2020 pour la version stable). Consultez l'état dans l'entrée d'état de Chrome.

Comprendre et détecter le changement

Pour comprendre les conséquences pratiques des nouvelles modifications par défaut, vous pouvez regarder cette démo.

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 le changement à 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 Chrome: comment activer l'indicateur chrome://flags/#reduced-referrer-granularity. — *Activation de l'indicateur.*

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 base de votre site Web utilise le référent, 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 le référent 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 stratégie de référent par défaut du navigateur (c'est-à-dire qu'aucune stratégie 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 envoyées à 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 contre les attaques CSRF, la journalisation et d'autres cas d'utilisation. Consultez Referer et Referrer-Policy: bonnes pratiques.
Vous pouvez vous aligner sur une règle spécifique avec vos partenaires si nécessaire et de manière transparente pour vos utilisateurs. Le contrôle des accès (lorsque les sites Web utilisent l'URL de provenance pour accorder un accès spécifique à leurs ressources à d'autres origines) peut être un cas de figure, bien que, avec le changement 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 la même direction en ce qui concerne le référent (voir les valeurs par défaut du navigateur et leur évolution dans Referer et Referrer-Policy: bonnes pratiques).

Implémenter des règles explicites et axées sur la confidentialité sur l'ensemble de votre site

Quel Referer doit être envoyé 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 du changement de Chrome, il est conseillé de définir une règle explicite renforçant la confidentialité comme strict-origin-when-cross-origin ou plus stricte dès maintenant.

Cela protège vos utilisateurs et rend le comportement de votre site Web plus prévisible dans les différents navigateurs. Surtout, cela vous donne le contrôle, plutôt que de laisser votre site dépendre des paramètres par défaut du navigateur.

Consultez Referrer et Referrer-Policy: bonnes pratiques pour en savoir plus sur la configuration d'une règle.

À propos de Chrome Enterprise

La règle d'entreprise Chrome ForceLegacyDefaultReferrerPolicy est disponible pour les administrateurs informatiques qui souhaitent forcer la règle par défaut précédente concernant l'URL de provenance (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 à nous faire ou un problème à signaler ? Envoyez vos commentaires sur l'intention de lancement de Chrome ou envoyez vos questions à @maudnals sur Twitter.

Merci à tous les contributeurs et commentateurs, en particulier à Kaustubha Govind, David Van Cleve, Mike West, Sam Dutton, Rowan Merewood, Jxck et Kayce Basques.