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.
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
surtrue
viaabout: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
Navigation
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.](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-navigation-209071cf80318.png?authuser=0000&hl=fr)
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.](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-subresourc-ee291fec730b8.png?authuser=0000&hl=fr)
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.](https://web.developers.google.cn/static/articles/schemeful-samesite/image/a-cross-scheme-form-submi-528e4c1eb4c83.png?authuser=0000&hl=fr)
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 intersitehttp://site.example/
, car le schéma ne correspond pas." - "Le cookie
cookie_name
a été traité comme intersite contrehttp://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 surLax
. - Si les cookies
Strict
etLax
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
requiertSecure
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.
- Cette solution échoue si l'URL à laquelle vous envoyez les cookies (ou
de configuration) n'est pas sécurisée. En effet,
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://
depuishttps://
- Connexion
ws://
depuishttp://
Intersites:
- Connexion
wss://
depuishttp://
ws://
connexion depuishttps://
Photo par Julissa Capdevilla sur Afficher