Présentation des cookies SameSite

Rowan Merewood

Chaque cookie contient une paire clé-valeur ainsi qu'un certain nombre d'attributs contrôler quand et où ce cookie est utilisé.

L'introduction de l'attribut SameSite (défini dans RFC6265bis). vous permet d'indiquer si votre cookie est limité à un cookie propriétaire sur le même site. Il est utile de comprendre exactement ce que "site" signifie ici. Le site est la combinaison du suffixe de domaine et de la partie du domaine qui avant celle-ci. Par exemple, le domaine www.web.dev fait partie du site web.dev.

Terme clé: si l'utilisateur est sur www.web.dev et demande une image à static.web.dev, il s'agit d'une requête SameSite.

La liste des suffixes publics définit les pages comptabilisées sur le même site. Cela ne dépend pas seulement des domaines de premier niveau comme .com, mais peut également inclure des services tels que github.io. Cela permet your-project.github.io et my-project.github.io pour être comptabilisés comme des sites distincts.

Terme clé: si l'utilisateur est sur your-project.github.io et demande une image à my-project.github.io est une requête intersite.

Utilisez l'attribut SameSite pour déclarer l'utilisation des cookies.

L'attribut SameSite d'un cookie offre trois méthodes différentes pour contrôler ce comportement. Vous pouvez choisir de ne pas spécifier l'attribut ou utiliser Strict ou Lax pour limiter le cookie aux requêtes provenant du même site.

Si vous définissez SameSite sur Strict, votre cookie ne peut être envoyé que dans un un contexte propriétaire c'est-à-dire si le site du cookie correspond au site affiché dans la barre d'adresse du navigateur. Ainsi, si le cookie promo_shown est défini comme suit:

Set-Cookie: promo_shown=1; SameSite=Strict

Lorsque l'utilisateur accède à votre site, le cookie est envoyé avec la requête, comme prévu. Toutefois, si l'utilisateur suit un lien vers votre site à partir d'un autre, le cookie n'est pas envoyé à cette requête initiale. Cela est utile pour les cookies liés à des fonctionnalités qui se trouvent toujours derrière un tag la navigation, comme changer un mot de passe ou effectuer un achat, restrictif pour un cookie tel que promo_shown. Si votre lecteur suit le lien sur le site, il veut que le cookie soit envoyé afin que sa préférence puisse être appliquée.

SameSite=Lax permet au navigateur d'envoyer le cookie avec ces extensions de niveau supérieur navigations. Par exemple, si un autre site fait référence au contenu de votre site, dans dans ce cas, en utilisant la photo de votre chat et en fournissant un lien vers votre article ce qui suit:

<p>Look at this amazing cat!</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Read the <a href="https://blog.example/blog/cat.html">article</a>.</p>

Avec un cookie défini sur Lax, comme suit:

Set-Cookie: promo_shown=1; SameSite=Lax

Lorsque le navigateur demande amazing-cat.png pour le blog de l'autre personne, votre n'envoie pas le cookie. Toutefois, lorsque le lecteur suit un lien vers cat.html sur votre site, cette demande inclut le cookie.

Nous vous recommandons d'utiliser SameSite de cette façon, en définissant des cookies qui affectent le site Web s'affichent pour Lax, et les cookies liés aux actions des utilisateurs pour Strict.

Vous pouvez également définir SameSite sur None pour indiquer que vous souhaitez que le cookie quel que soit le contexte. Si vous proposez un service utilisé par d'autres sites, par exemple des widgets, du contenu intégré, des programmes d'affiliation, de la publicité ou plusieurs sites, utilisez None pour vous assurer que votre intention est claire.

</ph> <ph type="x-smartling-placeholder">

Modifications apportées au comportement par défaut sans SameSite

L'attribut SameSite est largement accepté, mais il n'a pas encore été adopté. Auparavant, lorsque les cookies étaient définis sans SameSite, les cookies étaient envoyés par défaut dans tous les contextes, ce qui rend les utilisateurs vulnérables la fuite d’informations. Pour encourager les développeurs à indiquer leur intention et offrir aux utilisateurs une expérience plus sécurisée, la proposition de l'IETF, Amélioration incrémentielle des cookies présente deux modifications clés:

• Les cookies sans attribut SameSite sont traités comme SameSite=Lax.
• Les cookies avec SameSite=None doivent également spécifier Secure, ce qui signifie qu'ils nécessitent dans un contexte sécurisé.

Ces deux modifications sont rétrocompatibles avec les navigateurs qui ont correctement implémenté la version précédente de l'attribut SameSite navigateurs non compatibles avec les versions antérieures de SameSite. Ils sont destinés à à réduire les coûts à la dépendance aux navigateurs le comportement par défaut en définissant le comportement et l'utilisation prévue. Tous les clients qui ne reconnaissent pas SameSite=None doit l'ignorer.

SameSite=Lax par défaut

Si vous envoyez un cookie sans spécifier son attribut SameSite, le navigateur traite ce cookie comme s'il était défini sur SameSite=Lax. Nous vous recommandons tout de même définir explicitement SameSite=Lax pour rendre l'expérience utilisateur plus cohérente entre les navigateurs.

SameSite=None doit être sécurisé

Lorsque vous créez des cookies intersites à l'aide de SameSite=None, vous devez également les définir à Secure pour que le navigateur les accepte:

Set-Cookie: widget_session=abc123; SameSite=None; Secure

Vous pouvez tester ce comportement à partir de Chrome 76 en activant about://flags/#cookies-without-same-site-must-be-secure et à partir de Firefox 69 en définissant network.cookie.sameSite.noneRequiresSecure dans about:config

Nous vous recommandons également de remplacer les cookies existants par Secure dès que possible. Si vous utilisez des services qui fournissent du contenu tiers sur votre site, assurez-vous votre fournisseur de services met à jour ses cookies, ainsi que les extraits ou sur votre site afin de vous assurer qu'il utilise le nouveau comportement.

Recettes de cookies SameSite

Pour savoir comment mettre à jour vos cookies afin de gérer correctement ces modifications apportées à SameSite=None et sur les différences de comportement du navigateur, consultez la article complémentaire, Recettes de cookies SameSite.

Merci pour les contributions et les commentaires de Lily Chen, Malte Ubl et Mike West, Rob Dodson, Tom Steiner et Vivek Sekhar.

Image principale du cookie par Pille-Riin Priske sur Afficher