Schemeful SameSite

La définition de "same-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 au protocole HTTPS par défaut pour éviter tout problème dans la mesure du possible, ou poursuivez votre lecture pour en savoir plus sur les valeurs d'attribut SameSite requises.

Steve Bingler

Rowan Merewood

Remarque : Cet article fait partie d'une série sur les modifications de l'attribut de cookie SameSite qui inclut:

• Comprendre les cookies
• Présentation des cookies SameSite
• Recettes de cookies SameSite

Schemeful Same-Site modifie la définition d'un site (Web) en remplaçant le domaine enregistrable uniquement par le schéma et le domaine enregistrable. Vous trouverez plus de détails et d'exemples dans Comprendre les termes "same-site" et "same-origin".

Terme clé : cela signifie que la version HTTP non sécurisée d'un site (par exemple, http://siteweb.example et la version HTTPS sécurisée de ce site, https://siteweb.example) sont désormais considérées comme intersites l'une par rapport à l'autre.

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

Si vous n'avez pas encore entièrement mis à jour votre site Web, cette étape devrait être votre priorité. Toutefois, si les visiteurs de votre site passent du protocole HTTP au protocole HTTPS, certains de ces scénarios courants et le comportement des cookies SameSite associés sont décrits ci-dessous.

Avertissement : À long terme, l'objectif est de supprimer progressivement la prise en charge des cookies tiers par des alternatives protégeant la confidentialité. Définir SameSite=None; Secure sur un cookie pour lui permettre d'être envoyé entre différents schémas ne doit être considéré que comme une solution temporaire pour la migration vers le protocole HTTPS complet.

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

• Dans Chrome 86, activez about://flags/#schemeful-same-site. Suivez la progression sur la page État de Chrome.
• Dans Firefox 79, définissez network.cookie.sameSite.schemeful sur true via about:config. Suivez la progression via le problème Bugzilla.

L'une des principales raisons pour lesquelles SameSite=Lax a été défini comme paramètre par défaut pour les cookies était de les protéger contre la falsification des requêtes intersites (CSRF). Toutefois, le trafic HTTP non sécurisé offre toujours aux pirates informatiques la possibilité de falsifier des 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 défense supplémentaire contre ces attaques.

Scénarios courants de plusieurs schémas

Terme clé : dans les exemples ci-dessous, où les URL ont toutes le même domaine enregistrable (par exemple, site.example), mais des schémas différents (par exemple, http://site.example ou https://site.example), elles sont appelées schémas croisés les unes par rapport aux autres.

Navigation

Auparavant, la navigation entre les versions de différents schémas d'un site Web (par exemple, un lien de http://site.example vers https://site.example) permettait auparavant d'envoyer des cookies SameSite=Strict. Cela est désormais considéré comme une navigation intersite, ce qui signifie que les cookies SameSite=Strict seront bloqués.

Navigation entre plusieurs schémas : de HTTP à HTTPS

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Bloqué	⛔ Bloqué
SameSite=Lax	✓ Autorisé	✓ Autorisé
SameSite=None;Secure	✓ Autorisé	⛔ Bloqué

Chargement des sous-ressources...

Avertissement : Tous les principaux navigateurs bloquent le contenu mixte actif, tel que les scripts ou les iFrames. De plus, des navigateurs tels que Chrome et Firefox s'efforcent de mettre à niveau ou de bloquer le contenu mixte passif.

Toutes les modifications que vous apportez ici ne doivent être considérées que comme une solution temporaire pendant que vous effectuez la mise à niveau vers le protocole HTTPS complet.

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

Auparavant, le chargement d'une sous-ressource de schémas croisés sur une page autorisait l'envoi ou la définition de cookies SameSite=Strict ou SameSite=Lax. Ce processus est désormais traité 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.

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

Une page HTTP incluant une sous-ressource multi-schémas via HTTPS.

	HTTP → HTTPS	HTTPS → HTTP
SameSite=Strict	⛔ Bloqué	⛔ Bloqué
SameSite=Lax	⛔ Bloqué	⛔ Bloqué
SameSite=None;Secure	✓ Autorisé	⛔ Bloqué

PUBLIER un formulaire

Auparavant, l'envoi de versions entre plusieurs schémas d'un site Web permettait l'envoi des cookies définis avec SameSite=Lax ou SameSite=Strict. Ce processus est à présent traité comme une requête POST intersite : seuls les cookies SameSite=None peuvent être envoyés. Vous pouvez rencontrer ce scénario sur les sites qui présentent la version non sécurisée par défaut, mais mettre à 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 passe d'un contexte sécurisé (HTTPS, par exemple) à un contexte non sécurisé (par exemple, HTTP), tous les cookies seront bloqués pour ces requêtes, car les cookies tiers ou intersites nécessitent Secure.

Avertissement : La meilleure solution consiste à s'assurer que la page du formulaire et sa destination utilisent une connexion sécurisée de type HTTPS. Cela est particulièrement important si l'utilisateur saisit des informations sensibles dans le formulaire.

Envoi de formulaires pour plusieurs schémas du protocole HTTP au protocole 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 la messagerie pour les développeurs sont disponibles dans Chrome et Firefox.

À partir de Chrome 86, l'onglet Issue (Problème) de DevTools inclut les problèmes liés à Schemeful Same-Site. Les problèmes suivants peuvent être signalés pour votre site.

Problèmes de navigation:

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

Problèmes de chargement des sous-ressources:

• "Migrer entièrement vers HTTPS pour continuer à envoyer des cookies à des sous-ressources du même site" ou "Migrer entièrement vers HTTPS pour continuer à autoriser les cookies à être définis par des sous-ressources du même site" : vous avertit que les cookies seront bloqués dans une future version de Chrome.
• "Migrer entièrement vers HTTPS pour envoyer des cookies à des sous-ressources du même site" ou "Migrer entièrement vers HTTPS pour autoriser la définition de cookies par des sous-ressources sur le même site" : vous avertit que le cookie a été bloqué. Ce dernier avertissement peut également apparaître lors de la publication POST d'un formulaire.

Pour en savoir plus, consultez les conseils de test et de débogage pour Schemeful Same-Site.

Dans Firefox 79, avec network.cookie.sameSite.schemeful défini sur true via about:config, la console affichera un message concernant les problèmes liés à Schemeful Same-Site. Les éléments suivants peuvent s'afficher sur votre site:

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

Questions fréquentes

Mon site est déjà entièrement disponible sur HTTPS. Pourquoi les outils de développement de mon navigateur présentent-ils des problèmes ?

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

Une façon de résoudre ce problème consiste à 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 utilise automatiquement la version sécurisée à la place.

Que se passe-t-il si je ne parviens pas à passer au protocole HTTPS ?

Nous vous recommandons vivement de mettre à niveau entièrement votre site en HTTPS pour protéger vos utilisateurs. Toutefois, si vous n'êtes pas en mesure de le faire vous-même, nous vous conseillons de contacter votre fournisseur d'hébergement pour savoir s'il peut proposer cette option. Si vous effectuez l'auto-hébergement, Let's Encrypt fournit un certain nombre d'outils pour installer et configurer un certificat. Vous pouvez également essayer de déplacer votre site derrière un CDN ou un autre proxy capable de 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 à une URL sécurisée (ou définis à partir de celle-ci), vous pouvez réduire les protections à None.
  • Cette solution é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 requiert l'attribut Secure sur les cookies, ce qui signifie que ces derniers ne peuvent pas être envoyés ou configurés sur 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 le protocole HTTPS.
  • N'oubliez pas que ce n'est que temporaire, car les cookies tiers finiront par disparaître complètement.

En quoi mes cookies seront-ils affectés si je n'ai pas spécifié d'attribut SameSite ?

Les cookies sans attribut SameSite sont traités comme s'ils spécifiaient SameSite=Lax et le même comportement croisé 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 les mesures d'atténuation des attaques Lax + POST dans les questions fréquentes SameSite de Chromium.

Quel est l'impact des WebSockets ?

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

Même site:

• wss:// connexion depuis https://
• ws:// connexion depuis http://

Inter-sites:

• wss:// connexion depuis http://
• ws:// connexion depuis https://

Photo par Julissa Capdevilla sur Unsplash