Partager via

Gérer les changements de cookie SameSite dans le navigateur Chrome

  • Article

Qu’est-ce que SameSite ?

SameSite est une propriété qui peut être définie dans les cookies HTTP pour empêcher les attaques de falsification de requête intersites (CSRF) dans les applications web :

  • Lorsque SameSite est défini sur Lax, le cookie est envoyé dans les requêtes au sein du même site et dans les requêtes GET d’autres sites. Il n’est pas envoyé dans les requêtes GET qui sont interdomaines.
  • La valeur Strict garantit que le cookie est envoyé dans des requêtes uniquement au sein du même site.

Par défaut, la valeur SameSite n’est PAS définie dans les navigateurs et c’est la raison pour laquelle il n’existe aucune restriction sur les cookies envoyés dans les requêtes. Une application doit s’abonner à la protection CSRF en paramétrant Lax ou Strict selon leurs exigences.

Modifications SameSite et impact sur l’authentification

De récentes mises à jour des normes sur SameSite proposent de protéger les applications en définissant le comportement par défaut de SameSite sur l’absence de valeur définie sur Lax. Cette atténuation signifie que les cookies seront restreints sur les requêtes HTTP, à l’exception des requêtes GET provenant d’autres sites. En outre, une valeur None est introduite pour supprimer les restrictions concernant les cookies envoyés. Ces mises à jour seront bientôt publiées dans une prochaine version du navigateur Chrome.

Lorsque les applications web s’authentifient auprès de la plateforme Microsoft Identity à l’aide du mode de réponse « form_post », le serveur de connexion répond à l’application à l’aide d’une requête HTTP POST pour envoyer les jetons ou le code d’authentification. Étant donné que cette requête est une requête interdomaine (de login.microsoftonline.com à votre domaine, par exemple https://contoso.com/auth), les cookies qui ont été définis par votre application sont désormais soumis aux nouvelles règles de Chrome. Les cookies qui doivent être utilisés dans les scénarios intersites sont des cookies qui contiennent les valeurs état et nonce, qui sont également envoyées dans la requête de connexion. Il existe d'autres cookies déposés par Microsoft Entra ID pour maintenir la session.

Si vous ne mettez pas à jour vos applications web, ce nouveau comportement entraînera des échecs d’authentification.

Atténuation et exemples

Pour surmonter les échecs d’authentification, les applications web qui s’authentifient auprès de la plateforme d’identités Microsoft peuvent définir la propriété SameSite sur None pour les cookies utilisés dans les scénarios interdomaines lorsqu’ils s’exécutent sur le navigateur Chrome. D’autres navigateurs (voir ici pour obtenir une liste complète) suivent le comportement précédent de SameSite et n’incluront pas les cookies si SameSite=None est défini. C’est pourquoi, pour prendre en charge l’authentification sur plusieurs navigateurs, les applications web devront définir la valeur SameSite sur None uniquement sur Chrome et laisser la valeur vide sur les autres navigateurs.

Cette approche est illustrée dans l’exemple de code suivant.

La table suivante présente les demandes de tirage (pull request) qui ont contournées les modifications apportées à SameSite dans nos exemples ASP.NET et ASP.NET Core.

Exemple Demande de tirage (pull request)
Didacticiel incrémentiel sur les applications web ASP.NET Core Correctif pour cookie SameSite n° 261
Exemple d’application web ASP.NET MVC Correctif pour cookie SameSite n° 35
active-directory-dotnet-admin-restricted-scopes-v2 Correctif pour cookie SameSite n° 28

Pour plus d’informations sur la gestion des cookies SameSite dans ASP.NET et ASP.NET Core, consultez également :

Étapes suivantes

En savoir plus sur SameSite et le scénario des applications web :