Explication des Cookies SameSite
Sécurisez votre site en apprenant à marquer explicitement vos cookies intersites.
Les cookies permettent d'ajouter un état persistant aux sites Web. Au fil des ans, leurs capacités ont grandi et évolué, mais ont laissé à la plate-forme des problèmes hérités. Pour résoudre ceci, les navigateurs (y compris Chrome, Firefox et Edge) modifient leur comportement pour appliquer davantage de paramètres par défaut préservant la confidentialité.
Chaque cookie est une paire key=value avec un certain nombre d'attributs qui contrôlent quand et où ce cookie est utilisé. Vous avez probablement déjà utilisé ces attributs pour définir des éléments tels que des dates d'expiration ou pour indiquer que le cookie ne doit être envoyé que via HTTPS. Les serveurs définissent des cookies en envoyant l'en-tête Set-Cookie dans leur réponse. Pour tous les détails, vous pouvez consulter RFC6265bis, mais pour l'instant, voici un petit rappel.
Supposons que vous ayez un blog sur lequel vous souhaitez afficher une promotion "Les nouveautés" à vos utilisateurs. Les utilisateurs peuvent ignorer la promotion et ne la reverront plus pendant un certain temps. Vous pouvez stocker cette préférence dans un cookie, la définir pour qu'elle expire dans un mois (2 600 000 secondes) et l'envoyer uniquement via HTTPS. Cet en-tête ressemblerait à ceci :
Set-Cookie: promo_shown=1; Max-Age=2600000; Secure
Set-CookieLorsque votre lecteur consulte une page qui répond à ces exigences, c'est-à-dire qu'il utilise une connexion sécurisée et que le cookie date de moins d'un mois, son navigateur enverra cet en-tête dans sa requête :
Cookie: promo_shown=1
CookieVous pouvez également ajouter et lire les cookies disponibles sur ce site en JavaScript à l'aide de document.cookie. Effectuer une affectation à document.cookie créera ou remplacera un cookie avec cette clé. Par exemple, vous pouvez essayer ce qui suit dans la console JavaScript de votre navigateur :
→ document.cookie = "promo_shown=1; Max-Age=2600000; Secure"
← "promo_shown=1; Max-Age=2600000; Secure"La lecture de document.cookie affichera tous les cookies accessibles dans le contexte actuel, chaque cookie étant séparé par un point-virgule :
→ document.cookie;
← "promo_shown=1; color_theme=peachpuff; sidebar_loc=left"
document.cookie.Si vous essayez ceci sur une sélection de sites populaires, vous remarquerez que la plupart d'entre eux définissent bien plus que trois cookies. Dans la plupart des cas, ces cookies sont envoyés dans chaque requête à ce domaine, ce qui entraîne un certain nombre d'implications. La bande passante de chargement est souvent plus restreinte que le téléchargement pour vos utilisateurs, de sorte que la surcharge de toutes les requêtes sortantes ajoute un délai au premier octet. Soyez prudent dans le nombre et la taille des cookies que vous définissez. Utilisez l'attribut Max-Age pour vous assurer que les cookies ne sont pas conservés plus longtemps que nécessaire.
Que sont les cookies propriétaires et tiers ? #
Si vous revenez à la même sélection de sites que précédemment, vous avez probablement remarqué que des cookies étaient présents pour une variété de domaines, et pas seulement sur celui sur lequel vous naviguiez. Les cookies qui correspondent au domaine du site actuel, c'est-à-dire ce qui est affiché dans la barre d'adresse du navigateur, sont appelés cookies propriétaires. De même, les cookies provenant de domaines autres que le site actuel sont appelés cookies tiers. Il ne s'agit pas d'un libellé absolu, mais relatif au contexte de l'utilisateur : le même cookie peut être soit propriétaire, soit tiers, selon le site sur lequel l'utilisateur se trouve à ce moment-là.
En reprenant l'exemple ci-dessus, supposons que l'un de vos articles de blog contient une photo d'un chat particulièrement incroyable et qu'elle est hébergée sur /blog/img/amazing-cat.png. Parce que c'est une image tellement fabuleuse, une autre personne l'utilise directement sur son site. Si un visiteur a visité votre blog et possède le cookie promo_shown, lorsqu'il consulte amazing-cat.png sur le site de l'autre personne, ce cookie {nbsp}sera envoyé dans cette requête d'image. Ce n'est pas particulièrement utile puisque promo_shown n'est pas utilisé pour une raison quelconque sur le site de cette autre personne, cela ne fait qu'ajouter des surcharges à la requête.
S'il s'agit d'un effet involontaire, pourquoi faire cela ? C'est ce mécanisme qui permet aux sites de conserver leur état lorsqu'ils sont utilisés dans un contexte tiers. Par exemple, si vous intégrez une vidéo YouTube sur votre site, les visiteurs verront une option "Regarder plus tard" dans le lecteur. Si votre visiteur est déjà connecté à YouTube, cette session est rendue accessible dans le lecteur intégré grâce à un cookie tiers. Ainsi, le bouton "Regarder plus tard" enregistrera simplement la vidéo en un clic plutôt que de l'inviter à se connecter ou de l'éloigner de votre page et revenir à YouTube.
L'une des propriétés culturelles du Web est qu'il a tendance à être ouvert par défaut. Cela fait partie de ce qui a permis à tant de personnes de créer leur propre contenu et applications dessus. Cependant, cela a également entraîné un certain nombre de problèmes de sécurité et de confidentialité. Les attaques de falsification de requête intersites (CSRF) reposent sur le fait que des cookies sont joints à toute requête à une origine donnée, peu importe qui initie la requête. Par exemple, si vous visitez evil.example, cela peut déclencher des requêtes vers your-blog.example, et votre navigateur se fera un plaisir de joindre les cookies associés. Si votre blog ne fait pas attention à la façon dont il valide ces requêtes, evil.example peut déclencher des actions telles que la suppression de publications ou l'ajout de leur propre contenu.
Les utilisateurs sont également de plus en plus conscients de la manière dont les cookies peuvent être utilisés pour suivre leur activité sur plusieurs sites. Cependant, jusqu'à présent, il n'y avait aucun moyen d'indiquer explicitement votre intention en matière de cookies. Votre cookie promo_shown ne doit être envoyé que dans un contexte propriétaire, alors qu'un cookie de session pour un widget destiné à être intégré sur d'autres sites est intentionnellement présent pour fournir l'état de connexion dans un contexte tiers.
Indiquez explicitement l'utilisation des cookies avec l'attribut SameSite #
L'introduction de l'attribut SameSite (défini dans RFC6265bis) vous permet de déclarer si votre cookie doit être restreint à un contexte propriétaire ou de 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 juste avant. Par exemple, le domaine www.web.dev fait partie du site web.dev.
La liste des suffixes publics définit cela,. Il ne s'agit donc pas seulement de domaines de premier niveau tels que .com, mais également de services tels que github.io. Cela permet à your-project.github.io et my-project.github.io de compter comme des sites distincts.
L'introduction de l'attribut SameSite sur un cookie offre trois manières différentes de contrôler ce comportement. Vous pouvez choisir de ne pas spécifier l'attribut, ou vous pouvez utiliser Strict ou Lax pour limiter le cookie aux requêtes du même site.
Si vous définissez SameSite sur Strict, votre cookie ne sera envoyé que dans un contexte propriétaire. En termes d'utilisateur, le cookie ne sera envoyé que si le site pour le cookie correspond au site actuellement affiché dans la barre d'URL du navigateur. Donc, si le cookie promo_shown est défini comme suit :
Set-Cookie: promo_shown=1; SameSite=StrictLorsque l'utilisateur est sur votre site, le cookie sera envoyé avec la requête comme prévu. Cependant, lorsqu'on clique sur lien qui ramène à votre site, par exemple depuis un autre site ou via l'e-mail d'un ami, lors de cette requête initiale, le cookie ne sera pas envoyé. C'est une bonne chose lorsque vous avez des cookies associés à des fonctionnalités qui seront toujours à l'origine d'une navigation initiale, comme changer un mot de passe ou effectuer un achat, mais qui sont trop restrictifs pour promo_shown. Si l'un de vos lecteurs clique sur un lien menant vers votre site, il est préférable que le cookie soit envoyé afin que ses préférences puissent être appliquées.
C'est là que SameSite=Lax entre en jeu, en permettant l'envoi du cookie avec ces navigations de premier niveau. Revenons à l'exemple de l'article sur le chat ci-dessus, dans lequel un autre site référence votre contenu. Ce dernier utilise directement votre photo de chat et fournit un lien vers votre article d'origine.
<p>Regardez ce chat incroyable !</p>
<img src="https://blog.example/blog/img/amazing-cat.png" />
<p>Lisez l'article ici : <a href="https://blog.example/blog/cat.html"></a>.</p>Et le cookie a été défini comme suit :
Set-Cookie: promo_shown=1; SameSite=LaxLorsque le lecteur est sur le blog de l'autre personne, le cookie ne sera pas envoyé lorsque le navigateur effectue la requête amazing-cat.png. Cependant, si le lecteur clique sur le lien vers cat.html menant vers votre blog, cette requête inclura le cookie. Lax est donc un bon choix pour les cookies affectant l'affichage du site, Strict étant utile pour les cookies liés aux actions de votre utilisateur.
Enfin, il y a la possibilité de ne pas spécifier la valeur, ce qui était auparavant le moyen de déclarer implicitement que vous souhaitez que le cookie soit envoyé dans tous les contextes. Dans la dernière version de RFC6265bis, cela est rendu explicite en introduisant une nouvelle valeur de SameSite=None. Ainsi, vous pouvez utiliser None pour indiquer clairement que vous souhaitez intentionnellement que le cookie soit envoyé dans un contexte tiers.
None, Lax ou Strict.
Modifications du comportement par défaut sans SameSite #
Bien que l'attribut SameSite soit largement pris en charge, il n'a malheureusement pas été adopté massivement par les développeurs. Le principal défaut, l'envoi de cookies partout, signifie que tous les cas d'utilisation fonctionnent, mais laisse l'utilisateur vulnérable au CSRF et aux fuites d'informations non intentionnelles. Pour encourager les développeurs à exprimer leur intention et à offrir aux utilisateurs une expérience plus sûre, la proposition de l'IETF, Incrementally Better Cookies, présente deux changements clés :
- Les cookies sans l'attribut
SameSiteseront traités commeSameSite=Lax. - Les cookies avec l'attribut
SameSite=Nonedoivent également spécifierSecure, ce qui signifie qu'ils nécessitent un contexte sécurisé.
Chrome implémente ce comportement par défaut à partir de la version 84. Ils sont disponibles sur Firefox à partir de Firefox 69, qui en fera des comportements par défaut à l'avenir. Pour tester ces comportements dans Firefox, ouvrez la page about:config et configurez network.cookie.sameSite.laxByDefault. Edge prévoit également de modifier ses comportements par défaut.
SameSite=Lax par défaut #
No attribute set
Set-Cookie: promo_shown=1Si vous envoyez un cookie sans aucun attribut SameSite spécifié…
Comportement par défaut appliqué
Set-Cookie: promo_shown=1; SameSite=LaxLe navigateur traitera ce cookie comme si SameSite=Lax était spécifié.
Bien que cela soit destiné à appliquer une valeur par défaut plus sécurisée, vous devez idéalement définir un attribut SameSite explicite plutôt que de vous fier au navigateur pour l'appliquer à votre place. Cela rend votre intention pour le cookie explicite et améliore les chances d'une expérience cohérente entre les navigateurs.
SameSite=None doit être sécurisé #
Rejected
Set-Cookie: widget_session=abc123; SameSite=NoneLa configuration d'un cookie sans Secure sera rejetée.
Accepted
Set-Cookie: widget_session=abc123; SameSite=None; SecureVous devez vous assurer de coupler SameSite=None avec l'attribut Secure
Vous pouvez tester ce comportement à partir de Chrome 76 en activant about://flags/#cookies-without-same-site-must-be-secure et depuis Firefox 69 dans about:config en configurant network.cookie.sameSite.noneRequiresSecure.
Il est conseillé de l'appliquer lors de la configuration de nouveaux cookies et d'actualiser activement les cookies existants même s'ils n'approchent pas de leur date d'expiration.
Ces deux modifications sont rétrocompatibles avec les navigateurs qui ont correctement implémenté la version précédente de l'attribut SameSite, ou qui ne le prennent tout simplement pas en charge. En appliquant ces modifications à vos cookies, vous rendez explicite l'utilisation souhaitée de ces derniers plutôt que de vous fier au comportement par défaut du navigateur. De même, tous les clients qui ne reconnaissent pas SameSite=None pour l'instant doivent l'ignorer et continuer comme si l'attribut n'était pas défini.
Recettes de cookies SameSite #
Pour plus de détails sur comment mettre à jour vos cookies pour gérer les modifications apportées à SameSite=None et la différence de comportement des navigateurs, consultez l'article suivant : Recettes pour utiliser les cookies SameSite.
Merci pour les contributions et les commentaires de Lily Chen, Malte Ubl, Mike West, Rob Dodson, Tom Steiner et Vivek Sekhar
Cookie hero image par Pille-Riin Priske sur Unsplash