Se préparer pour les nouveaux paramètres de cookies SameSite=None; Secure

Jeudi 16 janvier 2020

Cet article est un post croisé issu du blog des développeurs Chromium. Il détaille la façon dont les modifications apportées à Chrome peuvent influer à terme sur le fonctionnement de votre site Web pour les utilisateurs.

En mai, Chrome a annoncé un modèle sécurisé par défaut pour les cookies, qui s'appuie sur un nouveau système de classification des cookies (spécification). Cette initiative s'inscrit dans nos efforts permanents pour améliorer la confidentialité et la sécurité sur l'ensemble du Web.

Chrome prévoit d'implémenter le nouveau modèle avec Chrome 80 en février 2020. Mozilla et Microsoft ont également décidé d'implémenter le nouveau modèle dans Firefox et Edge, selon leur propre calendrier. Les changements apportés à Chrome n'interviendront que dans plusieurs mois, mais il est important que les développeurs qui gèrent les cookies déterminent dès aujourd'hui s'ils sont prêts. Cet article de blog présente les concepts généraux. Pour en savoir plus, consultez les instructions destinées aux développeurs sur la page Explications sur les cookies SameSite du site web.dev.

Les sites Web intègrent généralement des services externes de publicité, de recommandations de contenus, de widgets tiers, d'intégration de réseaux sociaux et d'autres fonctionnalités. Lorsque vous naviguez sur le Web, ces services externes peuvent stocker des cookies dans votre navigateur, puis y accéder dans un second temps pour fournir des expériences personnalisées ou mesurer l'engagement de l'audience. Chaque cookie est associé à un domaine. Si le domaine associé à un cookie correspond à un service externe et non au site Web figurant dans la barre d'adresse de l'utilisateur, on parle de contexte intersite (ou tiers).

D'autres cas d'utilisation intersites sont moins évidents, par exemple lorsqu'une entité qui possède plusieurs sites Web utilise un cookie pour l'ensemble de ces propriétés. Bien que la même entité soit propriétaire du cookie et des sites Web, le contexte est considéré comme intersite ou "tiers" lorsque le domaine du cookie ne correspond pas aux sites utilisés pour accéder au cookie.

Le domaine du site ne correspond pas à celui du cookie

Lorsqu'une ressource externe hébergée sur une page Web accède à un cookie qui ne correspond pas au domaine du site, on parle de contexte intersite ou "tiers".

En revanche, l'accès aux cookies s'effectue dans un contexte SameSite (ou propriétaire) lorsque le domaine d'un cookie correspond à celui du site Web affiché dans la barre d'adresse de l'utilisateur. Les cookies SameSite sont couramment utilisés pour permettre aux internautes de rester connectés à des sites Web spécifiques, mémoriser leurs préférences et effectuer des analyses de site.

Le domaine du site correspond au domaine du cookie

Lorsqu'une ressource d'une page Web accède à un cookie correspondant au site que l'utilisateur consulte, on parle de contexte SameSite ou "propriétaire".

Aujourd'hui, si l'accès à un cookie n'est prévu que dans un contexte propriétaire, le développeur a le choix entre deux paramètres (SameSite=Lax ou SameSite=Strict) pour empêcher tout accès externe. Cependant, très peu de développeurs suivent cette pratique recommandée, et de nombreux cookies SameSite sont donc inutilement exposés à des menaces telles que les attaques par falsification de requêtes intersites.

Pour protéger davantage de sites Web et leurs utilisateurs, le nouveau modèle sécurisé par défaut suppose que tous les cookies doivent être protégés contre tout accès externe, sauf indication contraire. Les développeurs doivent utiliser un nouveau paramètre de cookie SameSite=None pour désigner les cookies autorisés dans un contexte intersite. Si l'attribut SameSite=None est présent, un attribut Secure supplémentaire doit être utilisé, de sorte que les cookies intersites ne soient accessibles que via des connexions HTTPS. Cette approche n'atténue pas tous les risques associés aux accès intersites, mais elle protège contre les attaques réseau.

Au-delà des avantages de sécurité immédiats, la déclaration explicite des cookies intersites permet une plus grande transparence et offre plus de choix aux utilisateurs. Par exemple, les navigateurs peuvent proposer aux utilisateurs des commandes précises pour gérer les cookies qui ne sont consultés que par un seul site, indépendamment des cookies utilisés sur plusieurs sites.

Restrictions Chrome à partir de février 2020

Avec la sortie de Chrome 80 en février, Chrome traitera les cookies qui n'ont pas de valeur SameSite déclarée comme des cookies SameSite=Lax. Seuls les cookies disposant du paramètre SameSite=None; Secure seront disponibles pour l'accès externe, à condition qu'ils soient accessibles à partir de connexions sécurisées. Les outils de suivi de l'état de la plate-forme Chrome pour SameSite=None et Secure continueront d'être mis à jour pour prendre en compte les dernières informations de lancement.

Mozilla a confirmé la compatibilité avec le nouveau modèle de classification des cookies et son intention d'implémenter les exigences SameSite=None; Secure pour les cookies intersites dans Firefox. Microsoft a récemment annoncé son intention de commencer à implémenter le modèle à titre expérimental dans Microsoft Edge 80.

Comment se préparer et difficultés connues

Si vous gérez des cookies intersites, vous devez appliquer le paramètre "SameSite=None; Secure" à ces cookies. Cette implémentation ne devrait pas poser de souci à la plupart des développeurs, mais nous vous recommandons vivement de commencer à effectuer des tests dès à présent pour identifier les complexités et les cas particuliers comme ceux-ci :

  • Tous les langages et toutes les bibliothèques n'acceptent pas encore la valeur "None", ce qui oblige les développeurs à définir directement l'en-tête du cookie. Ce dépôt GitHub fournit des instructions pour l'implémentation de "SameSite=None; Secure" dans plusieurs langages, bibliothèques et frameworks.
  • Certains navigateurs, y compris certaines versions de Chrome, de Safari et d'UC Browser, peuvent traiter la valeur None de façon inattendue, ce qui oblige les développeurs à coder des exceptions pour ces clients. C'est le cas pour les applications Android WebView fonctionnant avec des versions antérieures de Chrome. Voici la liste des clients incompatibles connus.
  • Nous conseillons aux développeurs d'applications de définir les paramètres SameSite cookie appropriés pour Android WebViews en fonction des versions de Chrome compatibles avec la valeur None, à la fois pour les cookies accessibles via les en-têtes HTTP(S) et via l'API CookieManager d'Android WebView, même si le nouveau modèle ne sera pas appliqué tout de suite dans Android WebView.
  • Les administrateurs informatiques des entreprises devront peut-être implémenter des règles spéciales pour rétablir temporairement l'ancien comportement du navigateur Chrome si certains services comme l'authentification unique ou les applications internes ne sont pas prêts pour le lancement en février.
  • Si vous avez accès à des cookies à la fois dans un contexte propriétaire et dans un contexte tiers, il peut être judicieux d'utiliser des cookies distincts pour profiter des avantages de sécurité de SameSite=Lax dans le contexte propriétaire.

La page SameSite Cookies Explained fournit des conseils spécifiques pour les situations ci-dessus, et indique par quels biais signaler les problèmes et poser des questions.

Pour tester l'effet du nouveau comportement de Chrome sur votre site ou sur les cookies que vous gérez, vous pouvez accéder à chrome://flags dans Chrome 76 ou version ultérieure, et activer les fonctionnalités expérimentales "SameSite by default cookies" et "Cookies without SameSite must be secure". En outre, ces fonctionnalités expérimentales seront activées automatiquement pour une partie des utilisateurs de la version bêta de Chrome 79. Certains utilisateurs de la version bêta ayant activé les fonctionnalités expérimentales peuvent rencontrer des problèmes d'incompatibilité avec les services qui ne sont pas encore compatibles avec le nouveau modèle. Dans ce cas, ils peuvent désactiver les fonctionnalités expérimentales de la version bêta en accédant à la page chrome://flags, puis en les désactivant.

Si vous gérez des cookies dont l'accès se limite à un contexte SameSite (cookies SameSite), aucune action n'est requise de votre part. Chrome empêchera automatiquement les entités externes d'accéder à ces cookies, même si l'attribut SameSite est manquant ou si aucune valeur n'est définie. Cependant, nous vous recommandons vivement d'appliquer une valeur SameSite adéquate (Lax ou Strict) et de ne pas compter sur le comportement par défaut du navigateur, car tous les navigateurs ne protègent pas les cookies SameSite par défaut.

Enfin, si vous avez des doutes sur la préparation des fournisseurs et d'autres prestataires fournissant les services de votre site Web, vous pouvez regarder si des avertissements s'affichent dans la console des outils pour les développeurs dans Chrome 77 ou version supérieure lorsqu'une page contient des cookies intersites sans paramètres obligatoires :

Un cookie associé à une ressource intersite sur (domaine du cookie) a été défini sans l'attribut "SameSite"

Certains fournisseurs (y compris certains services Google) implémenteront les modifications nécessaires dans les mois précédant la sortie de Chrome 80 en février. Nous vous conseillons de contacter vos partenaires pour savoir s'ils sont prêts.

Publié par Barb Palser, Chrome et partenariats Plate-forme Web