Schemeful SameSite

La définition de "même site" évolue pour inclure le schéma d'URL. Par conséquent, les liens entre les versions HTTP et HTTPS d'un site sont désormais considérés comme des requêtes intersites. Passez à HTTPS par défaut pour éviter les problèmes, si possible, ou lisez la suite pour savoir quelles valeurs d'attribut SameSite sont nécessaires.

Steven Bingler
Steven Bingler
GitHub
Rowan Merewood

Schemeful Same-Site modifie la définition d'un site (Web) en passant du domaine enregistrable uniquement au schéma + domaine enregistrable. Pour en savoir plus et obtenir des exemples, consultez Comprendre "même site" et "même origine".

Bonne nouvelle : si votre site Web est déjà entièrement mis à niveau vers HTTPS, vous n'avez rien à faire. Rien ne changera pour vous.

Si vous n'avez pas encore entièrement mis à niveau votre site Web, vous devez le faire en priorité. Toutefois, si vos visiteurs passent de HTTP à HTTPS, certains scénarios courants et le comportement associé des cookies SameSite sont décrits plus loin dans cet article.

Vous pouvez activer ces modifications pour les tests 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 de le problème Bugzilla.

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

Scénarios courants entre les schémas

La navigation entre les versions interschémas d'un site Web (par exemple, un lien de http://site.example vers https://site.example) permettait auparavant d'envoyer SameSite=Strict des cookies. Elle est désormais traitée comme une navigation intersite, ce qui signifie que les cookies SameSite=Strict seront bloqués.

Navigation multischéma déclenchée en suivant 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 interschémas de HTTP vers 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 que comme une solution temporaire pendant que vous travaillez à la mise à niveau vers HTTPS complet.

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

Le chargement d'une sous-ressource interschémas 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 multischéma 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, tandis que les cookies SameSite=None; Secure sont autorisés.
Une page HTTP incluant une sous-ressource interschémas via HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqué ⛔ Bloqué
SameSite=Lax ⛔ Bloqué ⛔ Bloqué
SameSite=None;Secure ✓ Autorisé ⛔ Bloqué

Envoi d'un formulaire

L'envoi entre les versions interschémas d'un site Web permettait auparavant d'envoyer des cookies définis avec SameSite=Lax ou SameSite=Strict. Cette opération est désormais traitée comme un 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 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 multischéma résultant de l'envoi d'un formulaire sur la version HTTP non sécurisée du site vers la version HTTPS sécurisée. Les cookies SameSite=Strict et SameSite=Lax sont bloqués, tandis que les cookies SameSite=None; Secure sont autorisés.
Envoi d'un formulaire interschémas de HTTP vers HTTPS.
HTTP → HTTPS HTTPS → HTTP
SameSite=Strict ⛔ Bloqué ⛔ Bloqué
SameSite=Lax ⛔ Bloqué ⛔ Bloqué
SameSite=None;Secure ✓ Autorisé ⛔ Bloqué

Comment 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 des Outils de développement 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 :

  • "Migrez entièrement vers HTTPS pour continuer à envoyer des cookies sur les requêtes du même site" : avertissement indiquant que le cookie sera bloqué dans une prochaine version de Chrome.
  • "Migrez entièrement vers 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 :

  • "Migrez entièrement vers HTTPS pour continuer à envoyer des cookies aux sous-ressources du même site" ou "Migrez entièrement vers HTTPS pour continuer à autoriser les sous-ressources du même site à définir des cookies" : avertissements indiquant que le cookie sera bloqué dans une prochaine version de Chrome.
  • "Migrez entièrement vers HTTPS pour envoyer des cookies aux sous-ressources du même site" ou "Migrez entièrement vers HTTPS pour autoriser les sous-ressources du même site à définir des cookies" : avertissements indiquant que le cookie a été bloqué. Le 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 Schemeful Same-Site.

À partir de Firefox 79, avec network.cookie.sameSite.schemeful 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 par rapport à http://site.example/, car le schéma ne correspond pas."
  • "Le cookie cookie_name a été traité comme un cookie intersite par rapport à http://site.example/, car le schéma ne correspond pas."

Questions fréquentes

Mon site est déjà entièrement disponible sur 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 includeSubDomain directive. 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 votre site à 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 vous auto-hébergez, alors 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 capable de fournir la connexion HTTPS.

Si cela n'est toujours pas possible, essayez de relâcher la protection SameSite sur les cookies concernés.

  • Dans les cas où seuls les cookies SameSite=Strict sont bloqués, vous pouvez réduire la protection à Lax.
  • Dans les cas où les cookies Strict et Lax sont bloqués et où 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 de contournement échouera 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 solution n'est que temporaire, car les cookies tiers finiront par être complètement supprimés.

Comment cela affecte-t-il mes cookies 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 interschémas s'applique également à ces cookies bien. Notez que l'exception temporaire aux méthodes non sécurisées s'applique toujours. Pour en savoir plus, consultez la section Lax + POST mitigation dans la FAQ Chromium SameSite .

Comment les WebSockets sont-ils affectés ?

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

Même site :

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

Intersite :

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