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.
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".
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.
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
surtrue
viaabout: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
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.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ Bloqué | ⛔ Bloqué |
SameSite=Lax
|
✓ Autorisé | ✓ Autorisé |
SameSite=None;Secure
|
✓ Autorisé | ⛔ Bloqué |
Chargement des sous-ressources...
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
.
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
.
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 avechttp://site.example/
, car le schéma ne correspond pas." - "Le cookie
cookie_name
a été traité comme intersite avechttp://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
etLax
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'attributSecure
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.
- 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,
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 depuishttps://
ws://
connexion depuishttp://
Inter-sites:
wss://
connexion depuishttp://
ws://
connexion depuishttps://
Photo par Julissa Capdevilla sur Unsplash