Recettes de cookies SameSite

Rowan Merewood

Chrome, Firefox, Edge et d'autres fournisseurs modifient leur comportement par défaut conformément à la proposition de l'IETF, Increasely Better Cookies, afin de:

• Les cookies sans attribut SameSite sont traités comme SameSite=Lax, ce qui signifie que le comportement par défaut consiste à limiter les cookies aux contextes propriétaires uniquement.
• Les cookies pour une utilisation intersite doivent spécifier SameSite=None; Secure pour permettre leur inclusion dans un contexte tiers.

Si vous ne l'avez pas déjà fait, mettez à jour les attributs de vos cookies tiers afin qu'ils ne soient pas bloqués à l'avenir.

Cas d'utilisation des cookies intersites ou tiers

Il existe un certain nombre de cas d'utilisation et de modèles courants dans lesquels les cookies doivent être envoyés dans un contexte tiers. Si vous fournissez l'un de ces cas d'utilisation ou dépendez-vous de l'un de ces cas d'utilisation, assurez-vous que le fournisseur ou vous-même mettez à jour ses cookies pour que le service fonctionne correctement.

Contenu d'un <iframe>

Le contenu d'un autre site affiché dans une <iframe> se trouve dans un contexte tiers. Voici quelques cas d'utilisation standards:

• Contenu intégré partagé à partir d'autres sites, tel que des vidéos, des cartes, des exemples de code et des posts sur les réseaux sociaux.
• Widgets provenant de services externes tels que les paiements, les agendas, et les fonctionnalités de réservation et de réservation
• Widgets tels que les boutons de réseaux sociaux ou les services antifraude qui créent des <iframes> moins évidents.

Les cookies peuvent être utilisés ici, entre autres, pour maintenir l'état de la session, stocker les préférences générales, activer des statistiques ou personnaliser le contenu des utilisateurs disposant d'un compte.

Étant donné que le Web est intrinsèquement composable, les <iframes> sont également utilisés pour intégrer le contenu affiché dans un contexte de premier niveau ou propriétaire. Tous les cookies utilisés par le site affiché dans l'iFrame sont considérés comme des cookies tiers. Si vous créez des sites que vous souhaitez que d'autres sites intègrent et que vous avez besoin de cookies pour qu'ils fonctionnent, vous devez également vous assurer qu'ils sont marqués pour une utilisation intersite ou que vous pouvez passer en toute simplicité sans ces sites.

Demandes "non sécurisées" sur plusieurs sites

Le terme "non fiable" peut sembler inquiétant ici, mais il fait référence à toute requête susceptible de changer d'état. Sur le Web, il s'agit principalement de requêtes POST. Les cookies marqués comme SameSite=Lax sont envoyés lors de navigations de premier niveau sécurisées, par exemple lorsqu'un utilisateur clique sur un lien pour accéder à un autre site. Toutefois, un envoi <form> à un autre site à l'aide de la méthode POST, par exemple, n'inclut pas les cookies.

Ce modèle est utilisé pour les sites qui peuvent rediriger l'utilisateur vers un service distant pour effectuer une opération avant de renvoyer, par exemple, la redirection vers un fournisseur d'identité tiers. Avant que l'utilisateur ne quitte le site, un cookie est défini. Il contient un jeton à usage unique. Il s'attend à ce que ce jeton puisse être vérifié sur la requête renvoyée afin de limiter les attaques de falsification de requête intersites (CSRF). Si cette requête renvoyée provient de la méthode POST, vous devez marquer les cookies comme SameSite=None; Secure.

Ressources distantes

Toute ressource distante d'une page, par exemple à partir de balises <img> ou <script>, peut s'appuyer sur l'envoi de cookies avec une requête. Les pixels de suivi et la personnalisation de contenu sont des cas d'utilisation courants.

Cela s'applique également aux requêtes envoyées à partir de votre code JavaScript à l'aide de fetch ou XMLHttpRequest. Si fetch() est appelé avec l'option credentials: 'include', ces requêtes sont susceptibles d'inclure des cookies. Pour XMLHttpRequest, les cookies attendus sont généralement indiqués par la valeur withCredentials pour true. Ces cookies doivent être correctement marqués pour être inclus dans les requêtes intersites.

Contenu d'une WebView

Dans une application spécifique à une plate-forme, une WebView est alimentée par un navigateur. Les développeurs doivent vérifier si les restrictions ou les problèmes qui affectent leurs applications s'appliquent également à leurs WebViews.

Android permet également à ses applications spécifiques à la plate-forme de définir des cookies directement à l'aide de l'API CookieManager. Comme pour les cookies définis à l'aide d'en-têtes ou de JavaScript, envisagez d'inclure SameSite=None; Secure s'ils sont destinés à être utilisés sur plusieurs sites.

Comment implémenter SameSite aujourd'hui

Marquez tous les cookies qui ne sont nécessaires que dans un contexte propriétaire comme SameSite=Lax ou SameSite=Strict, selon vos besoins. Si vous ne marquez pas ces cookies et que vous vous appuyez sur le comportement par défaut du navigateur pour les gérer, ils peuvent se comporter de manière incohérente entre les navigateurs et déclencher des avertissements de la console pour chaque cookie.

Set-Cookie: first_party_var=value; SameSite=Lax

Veillez à marquer tous les cookies nécessaires dans un contexte tiers comme SameSite=None; Secure. Les deux attributs sont obligatoires. Si vous spécifiez simplement None sans Secure, le cookie sera refusé. Pour tenir compte des différences d'implémentation des navigateurs, vous devrez peut-être utiliser certaines des stratégies d'atténuation décrites dans la section Gérer les clients incompatibles.

Set-Cookie: third_party_var=value; SameSite=None; Secure

Gérer les clients incompatibles

Étant donné que ces modifications visant à inclure None et le comportement de mise à jour par défaut sont encore relativement nouveaux, différents navigateurs les gèrent de manière différente. Vous pouvez consulter la page des mises à jour sur chromium.org pour obtenir la liste des problèmes connus, mais cette liste n'est peut-être pas exhaustive.

Une solution de contournement possible consiste à définir chaque cookie à la fois dans le nouveau et dans l'ancien style:

Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure

Les navigateurs qui implémentent le comportement le plus récent définissent le cookie avec la valeur SameSite. Les navigateurs qui n'implémentent pas le nouveau comportement ignorent cette valeur et définissent le cookie 3pcookie-legacy. Lors du traitement des cookies inclus, votre site doit d'abord vérifier la présence du nouveau style de cookie, puis revenir à l'ancien cookie s'il n'en trouve pas de nouveau.

L'exemple suivant montre comment procéder dans Node.js, à l'aide du framework Express et de son middleware d'cookie-parser:

const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());

app.get('/set', (req, res) => {
  // Set the new style cookie
  res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
  // And set the same value in the legacy cookie
  res.cookie('3pcookie-legacy', 'value', { secure: true });
  res.end();
});

app.get('/', (req, res) => {
  let cookieVal = null;

  if (req.cookies['3pcookie']) {
    // check the new style cookie first
    cookieVal = req.cookies['3pcookie'];
  } else if (req.cookies['3pcookie-legacy']) {
    // otherwise fall back to the legacy cookie
    cookieVal = req.cookies['3pcookie-legacy'];
  }

  res.end();
});

app.listen(process.env.PORT);

Cette approche nécessite un travail supplémentaire pour définir les cookies redondants et apporter des modifications au moment de la définition et de la lecture du cookie. Toutefois, elle devrait couvrir tous les navigateurs, quel que soit leur comportement, et maintenir le fonctionnement des cookies tiers.

Vous pouvez également détecter le client à l'aide de la chaîne user-agent lorsqu'un en-tête Set-Cookie est envoyé. Consultez la liste des clients incompatibles et utilisez une bibliothèque de détection d'user-agent adaptée à votre plate-forme, par exemple la bibliothèque ua-parser-js sur Node.js. Cette approche ne nécessite qu'une seule modification, mais le reniflage du user-agent peut ne pas détecter tous les utilisateurs concernés.

Prise en charge de SameSite=None dans les langages, les bibliothèques et les frameworks

La plupart des langages et des bibliothèques acceptent l'attribut SameSite pour les cookies. Toutefois, l'ajout de SameSite=None étant encore relativement récent, vous devrez peut-être contourner un comportement standard pour le moment. Ces comportements sont documentés dans le dépôt d'exemples SameSite sur GitHub.

Obtenir de l'aide

Les cookies sont utilisés partout sur le Web, et il est rare qu'une équipe de développement sache parfaitement où son site les définit et les utilise, en particulier dans les cas d'utilisation intersites. Lorsque vous rencontrez un problème, il peut s'agir de la première fois que quelqu'un le rencontre. N'hésitez donc pas à nous contacter:

• Soumettez un problème dans le dépôt d'exemples SameSite sur GitHub.
• Posez une question à l'aide du tag "samesite" sur StackOverflow.
• Pour les problèmes liés au comportement de Chromium, signalez un bug dans l'outil de suivi des problèmes Chromium.
• Suivez la progression de Chrome sur la page des mises à jour de SameSite.