Préparez-vous pour le nouveau SameSite = Aucun; Paramètres des cookies sécurisés

8

Article traduit par : SEO SEA Expertise. La traduction n’engage que l’auteur. Veuillez vous référer au texte originel (lien Source).

Google vient de publier un nouvel article sur son blog officiel. Pour les non anglophones, nous proposons une traduction de cet article.

Ceci est une publication croisée du blog des développeurs Chromium et est spécifique à la façon dont les modifications apportées à Chrome peuvent 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 (spec). 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 leur propre calendrier. Bien que les modifications de Chrome soient encore dans quelques mois, il est important que les développeurs qui gèrent les cookies évaluent leur niveau de préparation aujourd'hui. Ce billet de blog présente des concepts de haut niveau; veuillez consulter SameSite Cookies Explained sur web.dev pour des conseils aux développeurs.

Comprendre le contexte des cookies intersites et de même site

Les sites Web intègrent généralement des services externes pour la publicité, des recommandations de contenu, des widgets tiers, des 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 du public. 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 intersite (ou "tierce personne") le contexte.

Les cas d'utilisation intersites 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é soit propriétaire du cookie et des sites Web, cela compte toujours comme contexte intersite ou «tiers» lorsque le domaine du cookie ne correspond pas au (x) site (s) à partir duquel 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 intersite ou «tiers».

En revanche, l'accès aux cookies dans un même site (ou "Première fête") 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 garder les utilisateurs connectés sur des sites Web individuels, se souvenir de 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 du même site ou du contexte de «première partie».

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

Aujourd'hui, si un cookie est uniquement destiné à être accessible dans un contexte propriétaire, 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 exposés inutilement à des menaces telles que les attaques de type 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 les accès externes, sauf indication contraire. Les développeurs doivent utiliser un nouveau paramètre de cookie, SameSite = None, pour désigner les cookies pour l'accès intersite. Lorsque l'attribut SameSite = None est présent, un attribut Secure supplémentaire doit être utilisé pour que les cookies intersites ne soient accessibles que via des connexions HTTPS. Cela n'atténuera pas tous les risques associés à l'accès intersite, mais il fournira une protection contre les attaques réseau.

Au-delà des avantages immédiats pour la sécurité, la déclaration explicite des cookies intersites permet une plus grande transparence et un plus grand choix de l'utilisateur. Par exemple, les navigateurs pourraient offrir aux utilisateurs des contrôles précis pour gérer les cookies qui ne sont accessibles que par un seul site séparément des cookies accessibles sur plusieurs sites.

Application 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 SameSite = None; Les paramètres sécurisés seront disponibles pour l'accès externe, à condition qu'ils soient accessibles à partir de connexions sécurisées. Les suiveurs d'état de la plate-forme 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 SameSite = None; Exigences sécurisées pour les cookies intersites dans Firefox. Microsoft a récemment annoncé son intention de commencer à implémenter le modèle en commençant par une expérience dans Microsoft Edge 80.

Comment préparer; Complexités connues

Si vous gérez des cookies intersites, vous devrez appliquer le SameSite = None; Paramétrage sécurisé de ces cookies. La mise en œuvre devrait être simple pour la plupart des développeurs, mais nous vous encourageons fortement à commencer les tests dès maintenant pour identifier les complexités et les cas spéciaux, tels que les suivants:

  • Toutes les langues et bibliothèques ne prennent pas encore en charge la valeur None, ce qui oblige les développeurs à définir directement l'en-tête du cookie. Ce référentiel Github fournit des instructions pour implémenter SameSite = None; Sécurisé dans une variété de langues, bibliothèques et frameworks.
  • Certains navigateurs, y compris certaines versions de Chrome, Safari et UC Browser, peuvent gérer la valeur None de manière inattendue, obligeant les développeurs à coder des exceptions pour ces clients. Cela inclut les WebViews Android optimisés par les anciennes versions de Chrome. Voici une liste de clients incompatibles connus.
  • Les développeurs d'applications sont invités à déclarer les paramètres de cookies SameSite appropriés pour les vues Web Android basées sur des versions de Chrome compatibles avec la valeur Aucune, à la fois pour les cookies accessibles via les en-têtes HTTP (S) et via l'API CookieManager d'Android WebView, bien que le nouveau modèle ne être appliqué sur Android WebView jusqu'à plus tard.
  • Les administrateurs informatiques d'entreprise peuvent avoir besoin de mettre en œuvre des stratégies spéciales pour rétablir temporairement le navigateur Chrome au comportement hérité si certains services tels que l'authentification unique ou les applications internes ne sont pas prêts pour le lancement en février.
  • Si vous avez des cookies auxquels vous accédez à la fois dans un contexte premier et tiers, vous pouvez envisager d'utiliser des cookies distincts pour obtenir les avantages de sécurité de SameSite = Lax dans le contexte propriétaire.

SameSite Cookies Explained offre des conseils spécifiques pour les situations ci-dessus et 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 dans chrome: // flags dans Chrome 76+ et activer les expériences «SameSite par défaut cookies» et «Cookies sans SameSite doivent être sécurisés». De plus, ces tests seront automatiquement activés pour un sous-ensemble d'utilisateurs de Chrome 79 Beta. Certains utilisateurs de la version bêta avec les tests activés 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 bêta en accédant aux indicateurs chrome: // et en les désactivant.

Si vous gérez des cookies qui ne sont accessibles que dans un contexte de même site (cookies de même site), aucune action de votre part n'est requise; Chrome empêchera automatiquement l'accès à ces cookies par des entités externes, même si l'attribut SameSite est manquant ou qu'aucune valeur n'est définie. Cependant, nous vous recommandons fortement d'appliquer une valeur SameSite appropriée (Lax ou Strict) et de ne pas vous fier au comportement du navigateur par défaut car tous les navigateurs ne protègent pas les cookies du même site par défaut.

Enfin, si vous êtes préoccupé par l'état de préparation des fournisseurs et des autres fournisseurs de services sur 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 qui ne contiennent pas les paramètres requis:

Un cookie associé à une ressource intersite sur (domaine des cookies) a été défini sans l'attribut `SameSite`. Une future version de Chrome ne fournira des cookies avec des demandes intersites que s'ils sont définis avec "SameSite = None" et "Secure". Vous pouvez consulter les cookies dans les outils de développement sous Cookies de stockage d'applications et voir plus de détails sur https://www.chromestatus.com/feature/5088147346030592 et https://www.chromestatus.com/feature/5633521622188032.
Certains fournisseurs (y compris certains services Google) mettront en œuvre les modifications nécessaires dans les mois précédant Chrome 80 en février; vous pouvez contacter vos partenaires pour confirmer leur disponibilité.

Source