<ph type="x-smartling-placeholder">
Navigateurs pris en charge
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
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.
![Trois cookies intitulés "None", "Lax" ou "Strict" selon leur contexte](https://web.dev/static/articles/samesite-cookies-explained/image/three-cookies-labelled-no-495f9afccf1cd.png?authuser=19&hl=fr)
None
, Lax
ou Strict
.
Modifications apportées au comportement par défaut sans SameSite
Navigateurs pris en charge
-
<ph type="x-smartling-placeholder">
-
<ph type="x-smartling-placeholder">
-
-
<ph type="x-smartling-placeholder">
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 commeSameSite=Lax
. - Les cookies avec
SameSite=None
doivent également spécifierSecure
, 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