Préparez-vous aux nouveaux paramètres de cookies SameSite=None; Secure

Jeudi 16 janvier 2020

Ceci est une republication du
Chromium developer blog
et concerne spécifiquement la façon dont les changements apportés à Chrome pourraient affecter le fonctionnement de votre site web pour vos utilisateurs à l’avenir.

En mai, Chrome a annoncé
un modèle sécurisé par défaut pour les cookies, activé par un nouveau système de classification des cookies
(spécification). Cette
initiative
fait partie de nos efforts continus pour améliorer la confidentialité et la sécurité sur le web.

Chrome prévoit d’implémenter le nouveau modèle avec Chrome 80 en février 2020. Mozilla et Microsoft ont également indiqué leur intention d’implémenter le nouveau modèle dans Firefox et Edge, selon leurs propres calendriers. Bien que les changements de Chrome soient encore dans quelques mois, il est important que les développeurs qui gèrent des cookies évaluent leur état de préparation dès aujourd’hui. Cet article de blog présente des concepts de haut niveau ; veuillez consulter
SameSite Cookies Explained sur web.dev pour obtenir des conseils aux développeurs.

Comprendre le contexte des cookies inter-sites et du même site

Les sites web intègrent généralement des services externes pour la publicité, les recommandations de contenu, les widgets tiers, les intégrations sociales et d’autres fonctionnalités. Lorsque vous naviguez sur le web, ces services externes peuvent stocker des cookies dans votre navigateur et accéder ultérieurement à ces cookies pour offrir des expériences personnalisées ou mesurer l’engagement de l’audience. Chaque cookie a un domaine qui lui est associé. Si le domaine associé à un cookie correspond à un service externe et non au site web dans la barre d’adresse de l’utilisateur, cela est considéré comme un contexte inter-sites (ou “tiers”).

Les cas d’utilisation inter-sites moins évidents incluent les situations où une entité qui possède plusieurs sites web utilise un cookie sur ces propriétés. Bien que la même entité possède le cookie et les sites web, cela compte toujours comme un contexte inter-sites ou “tiers” lorsque le domaine du cookie ne correspond pas au(x) site(s) à partir duquel/desquels le cookie est consulté.

Lorsqu’une ressource externe sur une page web accède à un cookie qui ne correspond pas au domaine du site, il s’agit d’un contexte inter-sites ou “tiers”.

En revanche, l’accès aux cookies dans un contexte
du même site (ou “premier parti”) se produit lorsque le domaine d’un cookie correspond au domaine du site web dans la barre d’adresse de l’utilisateur. Les cookies du même site sont couramment utilisés pour maintenir les utilisateurs connectés à des sites web individuels, mémoriser leurs préférences et prendre en charge l’analyse du site.

Lorsqu’une ressource sur une page web accède à un cookie qui correspond au site que l’utilisateur visite, il s’agit d’un contexte du même site ou “premier parti”.

Un nouveau modèle pour la sécurité et la transparence des cookies

Aujourd’hui, si un cookie n’est destiné à être consulté que dans un contexte de premier parti, le développeur a la possibilité d’appliquer l’un des deux paramètres (SameSite=Lax ou
SameSite=Strict) pour empêcher l’accès externe. Cependant, très peu de développeurs suivent cette pratique recommandée, laissant un grand nombre de cookies du même site inutilement exposés à des menaces telles que les attaques
Cross-Site Request Forgery
.

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 l’accès externe, sauf indication contraire. Les développeurs doivent utiliser un nouveau paramètre de cookie, SameSite=None, pour désigner les cookies pour un accès inter-sites. Lorsque l’attribut SameSite=None est présent, un attribut Secure supplémentaire doit être utilisé afin que les cookies inter-sites ne puissent être consultés que via des connexions HTTPS. Cela n’atténuera pas tous les risques associés à l’accès inter-sites, mais fournira une protection contre les attaques réseau.

Au-delà des avantages immédiats en matière de sécurité, la déclaration explicite des cookies inter-sites permet une plus grande transparence et un meilleur choix pour l’utilisateur. Par exemple, les navigateurs pourraient offrir aux utilisateurs des contrôles précis pour gérer les cookies auxquels un seul site accède séparément des cookies auxquels plusieurs sites accèdent.

Application par Chrome à partir de février 2020

Avec 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 avec le paramètre
SameSite=None; Secure seront disponibles pour un accès externe, à condition qu’ils soient consultés à partir de connexions sécurisées. Les trackers d’état de la plateforme Chrome pour
SameSite=None
et
Secure
continueront d’être mis à jour avec les dernières informations de lancement.

Mozilla a affirmé son soutien au nouveau modèle de classification des cookies avec son
intention d’implémenter
les exigences SameSite=None; Secure pour les cookies inter-sites dans Firefox. Microsoft a récemment
annoncé
des plans pour commencer à implémenter le modèle à partir d’une expérience dans Microsoft Edge 80.

Comment se préparer ; Complexités connues

Si vous gérez des cookies inter-sites, vous devrez appliquer le paramètre SameSite=None; Secure à ces cookies. L’implémentation devrait être simple pour la plupart des développeurs, mais nous vous encourageons vivement à commencer les tests dès maintenant pour identifier les complexités et les cas particuliers, tels que les suivants :

• Tous les langages et bibliothèques ne prennent pas encore en charge la valeur None, ce qui oblige les développeurs à définir l’en-tête du cookie directement. Ce GitHub repository
  fournit des instructions pour implémenter SameSite=None; Secure dans une variété de langages, bibliothèques et frameworks.
• Certains navigateurs, y compris certaines versions de Chrome, Safari et UC Browser, pourraient gérer la valeur
  None de manières imprévues, obligeant les développeurs à coder des exceptions pour ces clients. Cela inclut les Android WebViews alimentés par des versions plus anciennes de Chrome. Voici une liste de
  clients incompatibles.
• connus. Il est conseillé aux développeurs d’applications de déclarer les paramètres de SameSite cookie
  appropriés pour les WebViews Android en fonction des versions de Chrome qui sont compatibles avec la valeur None , à la fois pour les cookies consultés via les en-têtes HTTP(S) et via Android
  WebView‘s
  CookieManager API,
  bien que le nouveau modèle ne sera appliqué sur Android WebView que plus tard.
• Les administrateurs informatiques d’entreprise peuvent avoir besoin de mettre en œuvre des politiques spéciales
  pour rétablir temporairement le comportement hérité du navigateur Chrome si certains services tels que l’authentification unique ou les applications internes ne sont pas prêts pour le lancement de février.
• Si vous avez des cookies auxquels vous accédez à la fois dans un contexte propriétaire et tiers, vous pourriez envisager
  d’utiliser des cookies distincts pour bénéficier des avantages de sécurité de SameSite=Lax
  dans le contexte propriétaire.

Explication des cookies SameSite
offre des conseils spécifiques pour les situations ci-dessus, ainsi que des canaux pour soulever des problèmes et des questions.

Pour tester l’effet du nouveau comportement de Chrome sur votre site ou les cookies que vous gérez, vous pouvez aller sur
chrome://flags dans Chrome 76+ et activer les expériences
“SameSite by default cookies” et
“Cookies without SameSite must be secure“. De plus,
ces expériences seront automatiquement activées pour un sous-ensemble d’utilisateurs de Chrome 79 Beta. Certains utilisateurs
Beta avec les expériences activées pourraient rencontrer des problèmes d’incompatibilité avec des services qui
ne prennent pas encore en charge le nouveau modèle ; les utilisateurs peuvent désactiver les expériences Beta en allant sur
chrome://flags et en les désactivant.

Si vous gérez des cookies auxquels on accède uniquement dans un contexte de même site (cookies same-site), aucune
action n’est requise de votre part ; Chrome empêchera automatiquement ces cookies d’être
accessibles par des entités externes, 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 appropriée (Lax ou Strict) et de ne pas
vous fier au comportement par défaut du navigateur, car tous les navigateurs ne protègent pas les cookies same-site par défaut.

Enfin, si vous êtes préoccupé par la préparation des fournisseurs et autres tiers qui fournissent des services à
votre site web, vous pouvez vérifier les avertissements de la console des outils de développement dans Chrome 77+ lorsqu’une page
contient des cookies intersites auxquels il manque les paramètres requis :

Certains fournisseurs (y compris certains services Google) mettront en œuvre les changements nécessaires dans les
mois précédant Chrome 80 en février ; vous souhaiterez peut-être contacter vos partenaires pour
confirmer leur préparation.

Publié par Barb Palser, Chrome et Web Platform Partnerships