Schemeful SameSite

Définition de "même-site" évolue pour inclure le schéma d'URL, de sorte que les liens entre les versions HTTP et HTTPS d'un site comptent désormais comme des requêtes intersites. Passez à HTTPS par défaut pour éviter tout problème lorsque cela est possible. Pour en savoir plus sur les valeurs d'attribut SameSite requises, poursuivez votre lecture.

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

Schéma SameSite modifie la définition d'un site (Web) en remplaçant uniquement le domaine enregistrable par le schéma + domaine enregistrable. Vous trouverez plus de détails et d'exemples dans Comprendre un même site et "same-origin" :

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

Si vous n'avez pas encore complètement mis à jour votre site Web, votre priorité est requise. Toutefois, s'il existe des cas où les visiteurs de votre site HTTPS, puis certains de ces scénarios courants et le cookie SameSite associé sont décrits ci-dessous.

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

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

L'une des principales raisons expliquant le passage à SameSite=Lax comme valeur par défaut pour afin de vous protéger contre la falsification de requête intersites (CSRF). Toutefois, le trafic HTTP non sécurisé offre toujours la possibilité aux pirates informatiques de falsifier les cookies qui seront ensuite utilisés sur la version HTTPS sécurisée sur votre site. La création de cette limite intersites supplémentaire entre les schémas permet une protection supplémentaire contre ces attaques.

Scénarios croisés courants

naviguer entre les différentes versions d'un site Web (par exemple, créer un lien depuis http://site.example à https://site.example) permettait auparavant SameSite=Strict cookies à envoyer. Cette pratique est désormais traitée ce qui signifie que les cookies SameSite=Strict seront bloqués.

Navigation multi-schéma déclenchée en suivant un lien dans la version HTTP non sécurisée d'un site vers la version HTTPS sécurisée. SameSite=Strict cookies bloqués, SameSite=Lax et SameSite=None; Les cookies sécurisés sont autorisés.
Navigation multiplate-forme du protocole HTTP au protocole HTTPS
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqué ⛔ Bloqué
SameSite=Lax ✓ Autorisé ✓ Autorisé
SameSite=None;Secure ✓ Autorisé ⛔ Bloqué

Chargement des sous-ressources...

Les modifications que vous apportez ici ne doivent être considérées comme une correction temporaire que pendant à passer au protocole HTTPS complet.

Les images, les iFrames et les requêtes réseau effectuées avec XHR ou Fetch.

Le chargement d'une sous-ressource de schéma croisé sur une page permettait auparavant Cookies SameSite=Strict ou SameSite=Lax à envoyer ou à définir. Maintenant, c'est de la même manière que toute autre sous-ressource signifie que tous les cookies SameSite=Strict ou SameSite=Lax seront bloqués.

De plus, même si le navigateur autorise les ressources provenant de schémas non sécurisés sur une page sécurisée, tous les cookies sont bloqués pour ces demandes, car les cookies tiers ou intersites nécessitent Secure.

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

Publier un formulaire

Auparavant, la publication entre les versions multi-schéma d’un site Web permettait de cookies définis sur SameSite=Lax ou SameSite=Strict à envoyer. Maintenant, c'est traité comme une requête POST intersite, seuls SameSite=None cookies peuvent être envoyés. Vous pouvez rencontrer ce scénario sur des sites qui présentent la version non sécurisée par défaut, mais faites passer les utilisateurs à la version sécurisée lors de la connexion ou formulaire de paiement.

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

Envoi de formulaire croisé résultant d'un formulaire sur la version HTTP non sécurisée du site soumis à la version HTTPS sécurisée. SameSite=Strict et SameSite=Cookies Lax bloqués et SameSite=None; Les cookies sécurisés sont autorisés.
Envoi de formulaires multi-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 destinés aux développeurs sont disponibles dans Chrome et Firefox.

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

Problèmes de navigation:

  • "Migrer complètement vers le protocole HTTPS pour continuer à recevoir des cookies sur le même site" "requests" : avertissement indiquant que le cookie sera bloqué dans une version ultérieure. de Chrome.
  • "Migrer entièrement vers le protocole HTTPS pour que les cookies soient envoyés pour les requêtes SameSite" – A avertissant que le cookie a été bloqué.

Problèmes de chargement des sous-ressources:

  • "Migrer entièrement vers le protocole HTTPS pour continuer à recevoir des cookies sur le même site" sous-ressources" ou "Migrez entièrement vers le protocole HTTPS pour continuer à autoriser les cookies défini par les sous-ressources du même site" : avertissements indiquant que le cookie sera bloqué dans une prochaine version de Chrome.
  • "Migrer entièrement vers le protocole HTTPS pour que les cookies soient envoyés aux sous-ressources du même site" ou "Migrer entièrement vers le protocole HTTPS pour autoriser les cookies d'un même site." subresources" : avertissements indiquant que le cookie a été bloqué. La seconde Un avertissement peut également s'afficher lors de la publication d'un formulaire.

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

À partir de Firefox 79, network.cookie.sameSite.schemeful étant défini sur true via about:config : la console affiche un message pour 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 http://site.example/, car le schéma ne correspond pas."
  • "Le cookie cookie_name a été traité comme intersite contre http://site.example/, car le schéma ne correspond pas."

Questions fréquentes

Mon site est déjà entièrement disponible en HTTPS. Pourquoi est-ce que je rencontre des problèmes dans les outils de développement de mon navigateur ?

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

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 contient accidentellement un lien non sécurisé, le navigateur utiliser automatiquement la version sécurisée à la place.

Que faire si je ne parviens pas à passer au protocole HTTPS ?

Bien que nous vous recommandions fortement de passer entièrement votre site au protocole HTTPS protéger vos utilisateurs. Si vous n'êtes pas en mesure de le faire vous-même, nous vous conseillons de contacter votre fournisseur d'hébergement pour voir s'il peut proposer cette option. Si vous auto-hébergez, Let's Encrypt fournit un certain nombre d'outils installer et configurer un certificat. Vous pouvez aussi envisager de déplacer votre site derrière un CDN ou un autre proxy pouvant fournir la connexion HTTPS.

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

  • Si seuls SameSite=Strict cookies sont bloqués, vous pouvez réduire la protection sur Lax.
  • Si les cookies Strict et Lax sont bloqués, et que votre les cookies sont envoyés à (ou définis à partir de) une URL sécurisée. Vous pouvez réduire le nombre à None.
    • Cette solution échoue si l'URL à laquelle vous envoyez les cookies (ou de configuration) n'est pas sécurisée. En effet, SameSite=None requiert Secure sur les cookies, ce qui signifie que ces cookies ne peuvent pas être envoyés. sur une connexion non sécurisée. Dans ce cas, vous ne pourrez pas accéder jusqu'à ce que votre site passe à HTTPS.
    • N'oubliez pas que cette mesure n'est que temporaire, car les cookies tiers finiront par être entièrement supprimé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 le spécifiaient SameSite=Lax. Le même comportement de schéma croisé s'applique à ces cookies bien. Notez que l'exception temporaire aux méthodes non sécurisées s'applique toujours. Atténuation des risques laxistes et POST dans Chromium SameSite Questions fréquentes pour en savoir plus.

Quel est l'impact sur WebSockets ?

Les connexions WebSocket seront toujours considérées comme un même site si elles sont identiques. la sécurité de la page.

Même site:

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

Intersites:

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

Photo par Julissa Capdevilla sur Afficher