Cette page a été traduite par l'API Cloud Translation.

Recettes de cookies SameSite

Rowan Merewood

Remarque : Cette page fait partie d'une série sur les modifications apportées aux attributs de cookie SameSite, qui comprend les éléments suivants :

Chrome, Firefox, Edge et d'autres navigateurs modifient leur comportement par défaut conformément à la proposition de l'IETF, Cookies de meilleure qualité de manière incrémentielle, de sorte que:

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 à usage intersites doivent spécifier SameSite=None; Secure pour permettre leur inclusion dans un contexte tiers.

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

Navigateurs pris en charge

Source

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 ou dépendez de l'un de ces cas d'utilisation, assurez-vous que vous ou le fournisseur mettez à jour leurs cookies pour que le service fonctionne correctement.

Contenu d'un élément `<iframe>`

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

Contenu intégré partagé depuis d'autres sites, comme des vidéos, des cartes, des exemples de code et des posts sur les réseaux sociaux.
Widgets de services externes tels que les paiements, les agendas, les réservations et les fonctionnalités de réservation.
Widgets tels que les boutons de réseaux sociaux ou les services de lutte contre la fraude qui créent des <iframes> moins visibles.

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 les statistiques ou personnaliser le contenu pour les utilisateurs disposant de comptes existants.

Schéma d'une fenêtre de navigateur où l'URL du contenu intégré ne correspond pas à l'URL de la page. — Si le contenu intégré ne provient pas du même site que le contexte de navigation de premier niveau, il s'agit d'un contenu tiers.

Étant donné que le Web est intrinsèquement composable, les <iframes> sont également utilisés pour intégrer le contenu consulté dans un contexte de premier niveau ou first party. 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 intégrer à d'autres sites et que vous avez besoin de cookies pour les faire fonctionner, vous devez également vous assurer qu'ils sont marqués pour une utilisation intersites ou que vous pouvez utiliser une solution de remplacement appropriée sans eux.

Requêtes "non sécurisées" entre les sites

"Non sécurisé" peut sembler inquiétant ici, mais il fait référence à toute requête pouvant être destinée à modifier l'é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 niveau supérieur sécurisées, par exemple lorsque vous cliquez sur un lien pour accéder à un autre site. Toutefois, une transmission <form> à un autre site à l'aide de POST n'inclut pas de cookies.

Schéma d'une requête passant d'une page à une autre. — Si la requête entrante utilise une méthode "sûre", la page envoie des cookies.

Ce modèle est utilisé pour les sites pouvant rediriger l'utilisateur vers un service distant pour effectuer une opération avant de revenir, par exemple, en le redirigeant vers un fournisseur d'identité tiers. Avant que l'utilisateur ne quitte le site, un cookie contenant un jeton à usage unique est défini. Ce jeton peut être vérifié dans la requête de retour pour atténuer les attaques de falsification de requêtes intersites (CSRF). Si cette requête de retour provient d'une requête POST, vous devez marquer les cookies comme SameSite=None; Secure.

Ressources distantes

Toute ressource distante d'une page, comme les balises <img> ou <script>, peut dépendre de l'envoi de cookies avec une requête. Les cas d'utilisation courants incluent les pixels de suivi et la personnalisation du contenu.

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 une valeur withCredentials pour true. Ces cookies doivent être marqués de manière appropriée pour être inclus dans les requêtes intersites.

Contenu dans une WebView

Une WebView dans une application spécifique à une plate-forme 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 aux WebViews de leurs applications.

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.

Implémenter `SameSite` dès aujourd'hui

Marquez 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 plutôt sur le comportement par défaut du navigateur pour les gérer, ils peuvent se comporter de manière incohérente d'un navigateur à l'autre et déclencher potentiellement des avertissements de console pour chaque cookie.

Set-Cookie: first_party_var=value; SameSite=Lax

Veillez à marquer les cookies nécessaires dans un contexte tiers comme SameSite=None; Secure. Ces 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 à mettre à jour le comportement par défaut sont encore relativement récentes, les différents navigateurs les gèrent de différentes manières. Vous pouvez consulter la page des mises à jour sur chromium.org pour obtenir la liste des problèmes connus, mais celle-ci n'est pas exhaustive.

Pour contourner ce problème, vous pouvez définir chaque cookie à la fois dans l'ancien et le nouveau style:

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

Les navigateurs implémentant le nouveau comportement 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 type de cookie, puis revenir au cookie ancien s'il ne parvient pas à en trouver un nouveau.

L'exemple suivant montre comment procéder dans Node.js, à l'aide du framework Express et de son middleware 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 des cookies redondants et apporter des modifications au moment de la configuration et de la lecture du cookie. Toutefois, il doit 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'agent utilisateur appropriée pour votre plate-forme, par exemple la bibliothèque ua-parser-js sur Node.js. Cette approche ne nécessite qu'une seule modification, mais l'analyse de l'agent utilisateur risque de 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 majorité des langages et des bibliothèques acceptent l'attribut SameSite pour les cookies. Toutefois, comme l'ajout de SameSite=None est encore relativement récent, vous devrez peut-être contourner certains comportements standards pour le moment. Ces comportements sont décrits 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 ait une connaissance complète des emplacements où son site les définit et les utilise, en particulier dans les cas d'utilisation intersites. Lorsque vous rencontrez un problème, il est possible que ce soit la première fois que quelqu'un le rencontre. N'hésitez donc pas à nous contacter:

Signalez un problème dans le dépôt d'exemples SameSite sur GitHub.
Posez une question dans la balise"samesite" sur StackOverflow.
En cas de problème avec le comportement de Chromium, signalez un bug dans l'outil de suivi des problèmes de Chromium.
Suivez la progression de Chrome sur la page des mises à jour SameSite.