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

Recettes de cookies SameSite

Rowan Merewood

</ph> Remarque : Cette page fait partie d'une série sur les modifications apportées à l'attribut de cookie SameSite, qui inclut les éléments suivants: <ph type="x-smartling-placeholder">

Chrome Firefox Edge tandis que d'autres modifient leur comportement par défaut proposition, Augmentation incrémentielle des cookies afin que:

Les cookies sans attribut SameSite sont traités comme SameSite=Lax, ce qui signifie que le comportement par défaut consiste à restreindre contextes uniquement.
Les cookies d'utilisation intersites doivent spécifier SameSite=None; Secure pour permettre l'inclusion dans un contexte tiers.

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

Navigateurs pris en charge

<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">
<ph type="x-smartling-placeholder">

Source

Cas d'utilisation des cookies intersites ou tiers

Il existe un certain nombre de cas d'utilisation courants et de modèles dans lesquels les cookies doivent être envoyées dans un contexte tiers. Si vous fournissez l'un de ces services ou dépendez de celui-ci, vérifiez que vous ou le fournisseur mettez à jour vos cookies assurer le bon fonctionnement du service.

Contenu dans une `<iframe>`

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

Contenu intégré partagé à partir d'autres sites (vidéos, cartes, exemples de code, et les posts sur les réseaux sociaux.
Les widgets provenant de services externes tels que les paiements, les agendas, les réservations et et de réservation.
Les widgets (boutons de réseau social ou services antifraude, par exemple) qui créent des éléments moins évidents <iframes>

Les cookies peuvent être utilisés ici pour, entre autres, maintenir l'état d'une session, stocker les préférences générales, activer les statistiques ou personnaliser le contenu pour les utilisateurs comptes existants.

Schéma d'une fenêtre de navigateur dans laquelle l'URL du contenu intégré ne correspond pas à l'URL de la page — </ph> Si le contenu intégré ne provient pas du même site que le contenu de premier niveau il s'agit du contenu tiers.

Comme le Web est intrinsèquement composable, les <iframes> sont également utilisés pour intégrer les contenus consultés dans un contexte de premier niveau ou propriétaire. Tous les cookies du site affichés dans l'iFrame sont considérés comme des cookies tiers. Si vous utilisez créer des sites que vous souhaitez que d'autres sites intègrent et qui ont besoin de cookies vous devez également vous assurer qu'elles sont destinées à une utilisation intersite peuvent s'arrêter en douceur sans eux.

"Dangereux" de requêtes sur les sites

"Dangereux" peut sembler préoccupant, mais il s'agit de toute demande qui pourrait être destinés à changer d'état. Sur le Web, il s'agit principalement de requêtes POST. Biscuits marqués comme SameSite=Lax sont envoyés lors d'une navigation sécurisée de premier niveau, comme un clic sur un pour accéder à un autre site. Cependant, quelque chose comme un envoi <form> à un site différent utilisant la méthode POST n'inclut pas de cookies.

Schéma d'une demande se déplaçant d'une page à une autre — </ph> Si la requête entrante utilise une balise , la page envoie des cookies.

Ce modèle est utilisé pour les sites qui peuvent rediriger l’utilisateur vers un pour effectuer une opération avant de renvoyer, par exemple rediriger vers un fournisseur d'identité tiers. Avant que l'utilisateur ne quitte le site, un cookie est contenant un jeton à usage unique, avec pour objectif vérifiés lors de la demande de retour pour atténuer Falsification de requête intersites (CSRF) contre les attaques. Si cette demande de retour arrive par le biais de la méthode POST, vous devez marquer la cookies en tant que SameSite=None; Secure.

Ressources distantes

Toute ressource distante sur une page, telle que les balises <img> ou <script>, peuvent s'appuyer sur des cookies envoyés avec une requête. Voici quelques cas d'utilisation courants : 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 la méthode Option credentials: 'include', ces demandes sont susceptibles d'inclure des cookies. Pour XMLHttpRequest, les cookies attendus sont généralement indiqués par un Valeur de withCredentials pour true. Ces cookies doivent être correctement signalés pour être inclus dans les requêtes intersites.

Contenu dans une WebView

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

Android autorise également ses applications propres à la plate-forme à définir des cookies directement à l'aide du 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 à une utilisation sur plusieurs sites.

Comment implémenter `SameSite` dès aujourd'hui

Marquer 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 s'appuient sur le comportement par défaut du navigateur pour les gérer, ils peuvent de manière incohérente entre les navigateurs et déclencher des avertissements dans la console pour chacun d'eux un 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 ne spécifiez que None sans Secure, le cookie sera refusé. Pour tenir compte des différences dans les implémentations de navigateur, vous devrez peut-être recourir à des mesures d'atténuation stratégies décrites dans la section Gérer les clients incompatibles.

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

Gérer les clients incompatibles

Parce que ces modifications pour inclure None et mettre à jour le comportement par défaut sont toujours sont relativement récentes, mais les navigateurs ne les gèrent pas toutes de la même manière. Vous pouvez parrainer à la page des mises à jour de chromium.org ; .

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

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

Les navigateurs qui implémentent le nouveau comportement définissent le cookie avec le SameSite. . Les navigateurs qui n'implémentent pas le nouveau comportement ignorent cette valeur et définissent le cookie 3pcookie-legacy. Lorsqu'il traite des cookies inclus, votre site doit vérifiez d'abord la présence du nouveau style de cookie, 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 ses 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 vous oblige à définir des cookies redondants et à change au moment de la définition et de la lecture du cookie. Cependant, il doit couvrir tous les navigateurs quel que soit leur comportement, et conserver les cookies tiers fonctionne correctement.

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

Compatibilité avec `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. Cependant, comme l'ajout de SameSite=None reste relativement récent, vous devrez peut-être contourner un comportement standard pour l'instant. 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 y travaille. d'avoir une connaissance complète de l'emplacement et de l'utilisation de leur site, en particulier dans les cas d'utilisation intersites. Lorsque vous rencontrez un problème, il peut s’agir de la première fois quelqu'un l'a déjà rencontré, alors n'hésitez pas à nous contacter:

Signaler un problème dans le Dépôt d'exemples SameSite sur GitHub.
Posez une question dans le "mêmesite" sur StackOverflow.
En cas de problème lié au comportement de Chromium, signalez un bug dans le Outil Chromium de suivi des problèmes :
Suivez la progression de Chrome sur le Page des mises à jour de SameSite