Schemeful SameSite

La définition de "même site" évolue pour inclure le schéma d'URL. Les liens entre les versions HTTP et HTTPS d'un site sont donc désormais comptabilisés comme des requêtes intersites. Passez à HTTPS par défaut pour éviter les problèmes dans la mesure du possible, ou lisez la suite pour en savoir plus sur les valeurs d'attribut SameSite requises.

Same-Site avec schéma modifie la définition d'un site (Web) en remplaçant le domaine enregistrable par le schéma + domaine enregistrable. Pour en savoir plus et obtenir des exemples, consultez Comprendre les concepts de "same-site" et de "same-origin".

La bonne nouvelle est que si votre site Web est déjà entièrement migré vers HTTPS, vous n'avez rien à faire. Rien ne changera pour vous.

Si vous n'avez pas encore complètement migré votre site Web, cela doit être votre priorité. Toutefois, si les visiteurs de votre site passent parfois d'HTTP à HTTPS, certains de ces scénarios courants et le comportement associé du cookie SameSite sont décrits plus loin dans cet article.

Vous pouvez activer ces modifications à des fins de test dans Chrome et Firefox.

  • À partir de Chrome 86, activez about://flags/#schemeful-same-site. Suivez la progression sur la page d'état de Chrome.
  • À partir de Firefox 79, définissez network.cookie.sameSite.schemeful sur true via about:config. Suivez la progression à l'aide du problème Bugzilla.

L'une des principales raisons de l'utilisation de SameSite=Lax par défaut pour les cookies était de se protéger contre la contrefaçon de requêtes intersites (CSRF). Toutefois, le trafic HTTP non sécurisé offre toujours aux pirates informatiques la possibilité de falsifier les cookies qui seront ensuite utilisés sur la version HTTPS sécurisée du site. La création de cette limite intersites supplémentaire entre les schémas offre une protection supplémentaire contre ces attaques.

Scénarios courants entre les schémas

Auparavant, la navigation entre les versions inter-schémas d'un site Web (par exemple, la création d'un lien entre http://site.example et https://site.example) permettait d'envoyer des cookies SameSite=Strict. Cette opération est désormais traitée comme une navigation intersites, ce qui signifie que les cookies SameSite=Strict seront bloqués.

Navigation entre les schémas déclenchée par un lien sur la version HTTP non sécurisée d'un site vers la version HTTPS sécurisée. Les cookies SameSite=Strict sont bloqués, tandis que les cookies SameSite=Lax et SameSite=None;Secure sont autorisés.
Navigation entre les schémas HTTP et HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqué ⛔ Bloqué
SameSite=Lax ✓ Autorisé ✓ Autorisé
SameSite=None;Secure ✓ Autorisé ⛔ Bloqué

Chargement des sous-ressources

Toute modification que vous apportez ici ne doit être considérée que comme une solution temporaire pendant que vous passez au HTTPS complet.

Les images, les iFrames et les requêtes réseau effectuées avec XHR ou Fetch sont des exemples de sous-ressources.

Le chargement d'une sous-ressource inter-schéma sur une page permettait auparavant d'envoyer ou de définir des cookies SameSite=Strict ou SameSite=Lax. Cette opération est désormais traitée de la même manière que toute autre sous-ressource tierce ou intersite, ce qui signifie que tous les cookies SameSite=Strict ou SameSite=Lax seront bloqués.

De plus, même si le navigateur autorise le chargement de ressources à partir de schémas non sécurisés sur une page sécurisée, tous les cookies seront bloqués sur ces requêtes, car les cookies tiers ou intersites nécessitent Secure.

Sous-ressource multi-scheme résultant d'une ressource de la version HTTPS sécurisée du site incluse dans la version HTTP non sécurisée. Les cookies SameSite=Strict et SameSite=Lax sont bloqués, et les cookies SameSite=None; Secure sont autorisés.
Une page HTTP incluant une sous-ressource multi-scheme via HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqué ⛔ Bloqué
SameSite=Lax ⛔ Bloqué ⛔ Bloqué
SameSite=None;Secure ✓ Autorisé ⛔ Bloqué

Envoyer un formulaire par POST

Auparavant, l'envoi de cookies définis avec SameSite=Lax ou SameSite=Strict était autorisé lors de la publication entre les versions multi-schémas d'un site Web. Cette opération est désormais traitée comme un POST intersite. Seuls les cookies SameSite=None peuvent être envoyés. Ce scénario peut se produire sur des sites qui présentent la version non sécurisée par défaut, mais qui mettent à niveau les utilisateurs vers la version sécurisée lors de l'envoi du formulaire de connexion ou de paiement.

Comme pour les sous-ressources, si la requête provient d'un contexte sécurisé (par exemple, HTTPS) vers un contexte non sécurisé (par exemple, HTTP), tous les cookies seront bloqués sur ces requêtes, car les cookies tiers ou intersites nécessitent Secure.

Envoi d'un formulaire entre les schémas, à partir d'un formulaire sur la version HTTP non sécurisée du site envoyé à la version HTTPS sécurisée. Les cookies SameSite=Strict et SameSite=Lax sont bloqués, et les cookies SameSite=None;Secure sont autorisés.
Envoi de formulaires entre les schémas HTTP et HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqué ⛔ Bloqué
SameSite=Lax ⛔ Bloqué ⛔ Bloqué
SameSite=None;Secure ✓ Autorisé ⛔ Bloqué

Comment puis-je tester mon site ?

Les outils et les messages pour les développeurs sont disponibles dans Chrome et Firefox.

À partir de Chrome 86, l'onglet Problèmes dans les outils pour les développeurs inclura les problèmes liés à Schemeful Same-Site. Les problèmes suivants peuvent être mis en évidence pour votre site.

Problèmes de navigation:

  • "Passez entièrement à HTTPS pour continuer à envoyer des cookies sur les requêtes de même site" : avertissement indiquant que le cookie sera bloqué dans une prochaine version de Chrome.
  • "Passez entièrement à HTTPS pour envoyer des cookies sur les requêtes du même site" : avertissement indiquant que le cookie a été bloqué.

Problèmes de chargement des sous-ressources:

  • "Passez entièrement à HTTPS pour continuer à envoyer des cookies aux sous-ressources du même site" ou "Passez entièrement à HTTPS pour continuer à autoriser les cookies à être définis par les sous-ressources du même site" : avertissements indiquant que le cookie sera bloqué dans une prochaine version de Chrome.
  • "Migrate entirely to HTTPS to have cookies sent to same-site subresources" (Migrer entièrement vers HTTPS pour envoyer des cookies aux sous-ressources du même site) ou "Migrate entirely to HTTPS to allow cookies to be set by same-site subresources" (Migrer entièrement vers HTTPS pour autoriser les cookies à être définis par les sous-ressources du même site) : avertissements indiquant que le cookie a été bloqué. Ce dernier avertissement peut également s'afficher lors de l'envoi d'un formulaire.

Pour en savoir plus, consultez Conseils de test et de débogage pour le même site avec schéma.

À partir de Firefox 79, lorsque network.cookie.sameSite.schemeful est défini sur true via about:config, la console affiche un message pour les problèmes de même site de schéma. Les éléments suivants peuvent s'afficher sur votre site:

  • "Le cookie cookie_name sera bientôt traité comme un cookie intersite par rapport à http://site.example/, car le schéma ne correspond pas."
  • "Le cookie cookie_name a été traité comme intersite par rapport à http://site.example/, car le schéma ne correspond pas."

Questions fréquentes

Mon site est déjà entièrement disponible en HTTPS. Pourquoi des problèmes s'affichent-ils dans les outils de développement de mon navigateur ?

Il est possible que certains de vos liens et sous-ressources pointent toujours vers des URL non sécurisées.

Pour résoudre ce problème, vous pouvez utiliser HTTP Strict-Transport-Security (HSTS) et la directive includeSubDomain. Avec HSTS + includeSubDomain, même si l'une de vos pages inclut accidentellement un lien non sécurisé, le navigateur utilisera automatiquement la version sécurisée.

Que faire si je ne peux pas passer à HTTPS ?

Nous vous recommandons vivement de passer entièrement à HTTPS pour protéger vos utilisateurs. Si vous ne pouvez pas le faire vous-même, nous vous suggérons de contacter votre fournisseur d'hébergement pour voir s'il peut vous proposer cette option. Si vous hébergez vous-même votre site, Let's Encrypt fournit un certain nombre d'outils pour installer et configurer un certificat. Vous pouvez également envisager de placer votre site derrière un CDN ou un autre proxy pouvant fournir la connexion HTTPS.

Si ce n'est toujours pas possible, essayez d'assouplir la protection SameSite sur les cookies concernés.

  • Si seuls les cookies SameSite=Strict sont bloqués, vous pouvez réduire la protection à Lax.
  • Si les cookies Strict et Lax sont bloqués et que vos cookies sont envoyés à (ou définis à partir de) une URL sécurisée, vous pouvez réduire la protection à None.
    • Cette solution de contournement échoue si l'URL à laquelle vous envoyez des cookies (ou à partir de laquelle vous les définissez) n'est pas sécurisée. En effet, SameSite=None nécessite l'attribut Secure sur les cookies, ce qui signifie que ces cookies ne peuvent pas être envoyés ni définis via une connexion non sécurisée. Dans ce cas, vous ne pourrez pas accéder à ce cookie tant que votre site n'aura pas été mis à niveau vers HTTPS.
    • N'oubliez pas que cette mesure n'est que temporaire, car les cookies tiers seront finalement abandonnés.

Quel est l'impact sur mes cookies si je n'ai pas spécifié d'attribut SameSite ?

Les cookies sans attribut SameSite sont traités comme s'ils avaient spécifié SameSite=Lax, et le même comportement inter-schéma s'applique également à ces cookies. Notez que l'exception temporaire aux méthodes non sécurisées s'applique toujours. Pour en savoir plus, consultez la mitigation Lax + POST dans les questions fréquentes sur SameSite de Chromium.

Quel est l'impact sur les WebSockets ?

Les connexions WebSocket sont toujours considérées comme du même site si elles présentent le même niveau de sécurité que la page.

Same-site:

  • Connexion wss:// de https://
  • Connexion ws:// de http://

Intersite:

  • Connexion wss:// de http://
  • Connexion ws:// de https://

Photo par Julissa Capdevilla sur Unsplash