Cookies - SameSite Attribute

Photo by Mohammad Rahmani on Unsplash

À partir de la version 84, Chrome définit par défaut l’attribut SameSite des cookies sur Lax. Les services utilisant des Third-party cookies peuvent être affectés s’ils n’ont pas configuré SameSite correctement.

Aperçu

Les cookies sont des mécanismes utilisés dans les services web pour stocker l’état, couramment utilisés pour maintenir les sessions de connexion, les paniers d’achat, le suivi publicitaire, etc. Cependant, l’utilisation généralisée des cookies entraîne également des problèmes de confidentialité et de sécurité, et SameSite a été introduit pour répondre à ces problèmes.

First-Party and Third-Party

Basé sur la source du cookie (Set-Cookie), chaque cookie a un domaine spécifique. En regardant l’URL actuelle dans le navigateur de l’utilisateur, si le domaine du cookie correspond à l’URL actuelle, il s’agit d’un cookie First-Party ; sinon, c’est un cookie Third-Party.

Third-party

Par exemple, lorsque vous naviguez sur le site a.com, une requête (request) est envoyée à third-party.com et reçoit un cookie de third-party.com. Étant donné que le navigateur inclut automatiquement les cookies ayant le même domaine dans les requêtes, si vous naviguez ensuite sur un autre site comme b.com et que celui-ci envoie également une requête à third-party.com, le serveur recevra le cookie. Pour ces deux sites, le cookie de third-party.com est Third-party.

First-party

Si vous naviguez sur un site web correspondant au domaine third-party.com, le cookie sera également envoyé. Dans ce cas, ce cookie est appelé First-party.

Same-Origin and Same-Site

L’exemple précédent mentionnait l’utilisation du domaine pour déterminer le type de cookie, mais une meilleure façon de le dire est de déterminer si le site (Site) est le même. Est-ce lié au Same-origin souvent rencontré ?

Cookies SameSite

Origin

L’origine (Origin) est composée du schéma, de l’hôte et du port. La méthode de détermination est très simple : si le schéma, l’hôte et le port de deux URL sont tous identiques, elles sont Same-origin ; sinon, elles sont Cross-origin.

Site

La détermination du Same-Site implique les Effective top-level domains (eTLD). Tous les eTLD sont définis dans la Public Suffix List, et un site est composé d’un eTLD plus un préfixe.

Par exemple : github.io existe dans la Public Suffix List. L’ajout d’un préfixe (par exemple, a.github.io) en fait un site. Par conséquent, a.github.io et b.github.io sont deux sites différents (Cross-site).

example.com n’existe pas dans la Public Suffix List, mais .com si, donc example.com est un site, et a.example.com et b.example.com sont le même site (Same-site).

Notez que le site n’inclut pas le port, donc même si les ports sont différents, ils peuvent toujours être Same-site.

Why SameSite?

Le mécanisme où “toute requête porte les cookies de ce domaine” a également apporté des problèmes de sécurité et autres, le plus important étant le Cross-site request forgery (CSRF).

CSRF

Supposons qu’un utilisateur se soit connecté à example.com et ait obtenu un cookie. Lorsque l’utilisateur navigue sur un site malveillant evil.com, le JavaScript de ce site peut envoyer une requête POST à example.com/pay?amount=1000. Le navigateur inclura automatiquement le cookie de example.com, et l’utilisateur paiera 1000 dollars sans le savoir. Le serveur ne peut pas déterminer d’où vient cette requête.

Limitations

Les cookies eux-mêmes ne peuvent pas être configurés pour être envoyés uniquement dans un environnement First-party, donc les requêtes portent des cookies dans n’importe quel environnement. Le serveur ne peut pas identifier la source de la requête et ne peut que répondre comme d’habitude, ce qui fait gaspiller de la bande passante au client pour envoyer des cookies inutiles.

Solution

Avec l’attribut SameSite, nous pouvons configurer individuellement les conditions d’envoi des cookies dans différents environnements.

SameSite

L’attribut SameSite a trois valeurs. Le régler sur Strict ou Lax peut restreindre l’envoi des cookies uniquement dans les requêtes Same-Site. S’il est laissé vide, le comportement dépend du navigateur ; pour Chrome, la valeur par défaut est Lax.

Strict

Les cookies sont envoyés uniquement dans un environnement First-party. Cependant, il y a un problème : supposons qu’un utilisateur voit un lien vers une publication Facebook sur example.com (disons fb.com). Même si l’utilisateur s’est connecté à fb.com et possède un cookie, cliquer sur le lien n’enverra pas le cookie car les deux sites sont Cross-site, ils ne verront donc que la page de connexion.

Par conséquent, Strict convient aux actions sensibles, telles que supprimer des publications, effectuer des paiements, etc.

Lax

Pour remédier aux limitations trop strictes de Strict, Lax autorise l’envoi de cookies même dans des situations Cross-site dans les cas suivants :

Saisie d’une URL dans la barre d’adresse
Clic sur un lien <a href="...">
Envoi d’un formulaire <form method="GET">
Prerendering <link rel="prerender" href="...">

Ces cas ont deux points communs : ce sont tous des requêtes GET et ils déclenchent tous une Navigation de niveau supérieur (Top-level Navigation). Cela évite le problème de Strict nécessitant de se reconnecter à chaque fois, et empêche également l’envoi de cookies sans le savoir lors de la navigation sur d’autres sites web.

Lax + POST

Cependant, pour éviter de casser certains flux de connexion existants, Chrome assouplit actuellement légèrement la restriction pour SameSite=Lax, donnant aux développeurs plus de temps pour s’adapter.

Dans les deux minutes suivant la définition du cookie, quelle que soit la méthode de requête (Request Method), tant qu’elle déclenche une navigation de page de niveau supérieur, le cookie sera envoyé. Cela signifie que si le navigateur change de page, par exemple en envoyant un formulaire <form method="POST">.

Pour plus de détails, veuillez consulter le fil de discussion sur Lax + POST.

None

Pour envoyer un Third-party cookie, vous devez définir SameSite=None; Secure. Oui, à partir de maintenant, si vous souhaitez envoyer un Third-party cookie dans un environnement de test, veuillez préparer https://localhost.

De plus, l’envoi de Cross-Origin Requests via XHR/Fetch nécessite de définir withCredentials: true pour envoyer le cookie et rendre effectif le Set-Cookie dans l’en-tête de réponse. Le serveur doit également définir Access-Control-Allow-Credentials: true dans l’en-tête de réponse pour que JavaScript puisse accéder au contenu de la réponse.

Navigateurs non pris en charge

Tous les navigateurs ne prennent pas encore en charge les dernières règles SameSite, de sorte que certaines solutions de contournement (Workarounds) temporaires peuvent être ajoutées sur le serveur pour prendre en charge plusieurs navigateurs :

Définir les deux cookies

Cette méthode peut résoudre les problèmes pour presque tous les navigateurs, mais l’inconvénient est qu’il y aura deux copies du cookie :

Set-cookie: name=value; SameSite=None; Secure
Set-cookie: name-legacy=value; Secure

Code côté serveur :

if (req.cookies['name']) {
  // Utiliser le nouveau s'il est disponible
  cookieVal = req.cookies['name'];
} else if (req.cookies['name-legacy']) {
  // Sinon utiliser l'ancien
  cookieVal = req.cookies['name-legacy'];
}

User Agent

Déterminez le navigateur en utilisant le User agent de la requête pour décider du contenu de Set-Cookie. Cette méthode ne nécessite que de modifier le code définissant le cookie, sans changer la partie analyse (Parsing). Cependant, cette méthode de jugement implique plus de variables et rend plus facile la définition du mauvais cookie.

Bilan

Les cookies sans attribut SameSite défini seront par défaut SameSite=Lax et ne pourront pas être envoyés dans un environnement Cross-site.
Pour envoyer des cookies en Cross-site, vous devez définir SameSite=None; Secure.
Vous pouvez utiliser le SameSite sandbox pour tester si votre navigateur actuel est conforme aux dernières règles SameSite.