La definizione di "same-site" si sta evolvendo per includere lo schema URL, quindi i link tra le versioni HTTP e HTTPS di un sito ora vengono conteggiati come richieste cross-site. Esegui l'upgrade a HTTPS per impostazione predefinita per evitare problemi, ove possibile, oppure continua a leggere per conoscere i dettagli sui valori degli attributi SameSite necessari.
Schemeful Same-Site modifica la definizione di un sito (web) solo dal dominio registrabile allo schema + dominio registrabile. Puoi trovare ulteriori dettagli ed esempi in Informazioni su "stesso sito" e "stesso-origine".
La buona notizia è che se il tuo sito web è già stato completamente aggiornato a HTTPS, non devi preoccuparti di nulla. Non cambierà nulla per te.
Se non hai ancora eseguito l'upgrade completo del tuo sito web, questa dovrebbe essere la tua priorità.
Tuttavia, se i visitatori del tuo sito passano da HTTP a HTTPS, vengono descritti di seguito alcuni di questi scenari comuni e il comportamento dei cookie SameSite
associato.
Puoi attivare queste modifiche per i test sia in Chrome sia in Firefox.
- A partire da Chrome 86, attiva
about://flags/#schemeful-same-site
. Monitora l'avanzamento sulla pagina Stato di Chrome. - In Firefox 79, imposta
network.cookie.sameSite.schemeful
sutrue
tramiteabout:config
. Monitora l'avanzamento tramite il problema di Bugzilla.
Uno dei motivi principali della modifica a SameSite=Lax
come predefinita per i cookie è la protezione contro la falsificazione di richieste su più siti (CSRF). Tuttavia, il traffico HTTP non sicuro presenta ancora l'opportunità agli utenti malintenzionati di rete di modificare i cookie che verranno utilizzati nella versione HTTPS sicura del sito. La creazione di questo ulteriore confine tra siti tra gli schemi fornisce
ulteriore difesa da questi attacchi.
Scenari comuni tra schemi
Navigazione
Se navighi tra versioni cross-scheme di un sito web (ad esempio, un link da http://site.example a https://site.example) consentirebbe in precedenza l'invio dei cookie SameSite=Strict
. Ora viene considerata una navigazione tra siti, il che significa che i cookie SameSite=Strict
verranno bloccati.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ Bloccato | ⛔ Bloccato |
SameSite=Lax
|
✓ Consentito | ✓ Consentito |
SameSite=None;Secure
|
✓ Consentito | ⛔ Bloccato |
Caricamento delle risorse secondarie in corso...
Eventuali modifiche apportate qui devono essere considerate correzioni temporanee solo se esegui l'upgrade all'estensione HTTPS completa.
Esempi di risorse secondarie includono immagini, iframe e richieste di rete effettuate con XHR o Fetch.
Il caricamento di una sottorisorsa tra schemi su una pagina consentiva in precedenza l'invio o l'impostazione di cookie SameSite=Strict
o SameSite=Lax
. Ora, questo viene
trattato come qualsiasi altra sottorisorsa di terze parti o tra siti,
il che significa che qualsiasi cookie SameSite=Strict
o SameSite=Lax
verrà bloccato.
Inoltre, anche se il browser consente il caricamento di risorse di schemi non sicuri su una pagina sicura, tutti i cookie verranno bloccati in queste richieste poiché i cookie di terze parti o tra siti richiedono Secure
.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ Bloccato | ⛔ Bloccato |
SameSite=Lax
|
⛔ Bloccato | ⛔ Bloccato |
SameSite=None;Secure
|
✓ Consentito | ⛔ Bloccato |
PUBBLICARE un modulo
La pubblicazione tra versioni di un sito web su più schemi in precedenza consentiva l'invio dei cookie impostati con SameSite=Lax
o SameSite=Strict
. Ora questo viene trattato come un POST tra siti. È possibile inviare solo SameSite=None
cookie. Questo scenario potrebbe verificarsi sui siti che presentano la versione non sicura per impostazione predefinita, ma esegui l'upgrade degli utenti alla versione protetta all'invio del modulo di accesso o check-out.
Come per le risorse secondarie, se la richiesta passa da un contesto sicuro, ad esempio HTTPS, a uno non sicuro, ad esempio HTTP, contesto, tutti i cookie verranno bloccati in queste richieste poiché i cookie di terze parti o tra siti richiedono Secure
.
HTTP → HTTPS | HTTPS → HTTP | |
SameSite=Strict
|
⛔ Bloccato | ⛔ Bloccato |
SameSite=Lax
|
⛔ Bloccato | ⛔ Bloccato |
SameSite=None;Secure
|
✓ Consentito | ⛔ Bloccato |
Come posso testare il mio sito?
Gli strumenti e i messaggi per sviluppatori sono disponibili in Chrome e Firefox.
A partire da Chrome 86, la scheda Problema in DevTools include i problemi relativi allo stesso sito di Schemeful. Per il tuo sito potrebbero essere evidenziati i seguenti problemi.
Problemi relativi alla navigazione:
- "Esegui la migrazione completa a HTTPS per continuare a ricevere i cookie nelle richieste dello stesso sito": un avviso che indica che il cookie verrà bloccato in una versione futura di Chrome.
- "Esegui la migrazione completa a HTTPS per ricevere i cookie nelle richieste dello stesso sito": un avviso che indica che il cookie è stato bloccato.
Problemi di caricamento delle sottorisorse:
- "Esegui la migrazione completa a HTTPS per continuare a ricevere i cookie nelle sottorisorse dello stesso sito" o "Esegui la migrazione completa a HTTPS per continuare a consentire l'impostazione dei cookie dalle sottorisorse dello stesso sito": avvisi che indicano che il cookie verrà bloccato in una versione futura di Chrome.
- "Esegui la migrazione completa a HTTPS per fare in modo che i cookie vengano inviati alle sottorisorse dello stesso sito" o "Esegui la migrazione completa a HTTPS per consentire l'impostazione dei cookie dalle sottorisorse dello stesso sito": avvisi che indicano che il cookie è stato bloccato. Il secondo avviso può essere visualizzato anche quando si PUBBLICA un modulo.
Ulteriori dettagli sono disponibili in Suggerimenti di test e debug per Schemeful Same-Site.
In Firefox 79, con network.cookie.sameSite.schemeful
impostato su true
tramite about:config
, nella console verrà visualizzato il messaggio relativo ai problemi relativi a Schemeful Same-Site.
Sul tuo sito potresti visualizzare:
- "Il cookie
cookie_name
verrà presto trattato come cookie cross-site rispetto ahttp://site.example/
perché lo schema non corrisponde." - "Il cookie
cookie_name
è stato trattato come cross-site rispetto ahttp://site.example/
perché lo schema non corrisponde."
Domande frequenti
Il mio sito è già completamente disponibile su HTTPS. Perché vedo problemi nei DevTools del mio browser?
È possibile che alcuni link e sottorisorse rimandino ancora a URL non sicuri.
Un modo per risolvere il problema è utilizzare HTTP Strict-Transport-Security (HSTS) e l'istruzione includeSubDomain
. Con HSTS + includeSubDomain
, anche se una delle tue pagine include accidentalmente un link non sicuro, il browser utilizzerà automaticamente la versione protetta.
Che cosa succede se non posso eseguire l'upgrade a HTTPS?
Sebbene consigliamo vivamente di eseguire completamente l'upgrade del sito a HTTPS per proteggere gli utenti, se non sei in grado di farlo autonomamente, ti consigliamo di rivolgerti al tuo provider host per verificare se può offrire questa opzione. Se esegui l'hosting autonomo, Let's Encrypt fornisce una serie di strumenti per installare e configurare un certificato. Puoi anche valutare lo spostamento del sito dietro una rete CDN o un altro proxy in grado di fornire la connessione HTTPS.
Se ciò non fosse ancora possibile, prova a ridurre la protezione SameSite
sui
cookie interessati.
- Nei casi in cui vengono bloccati solo
SameSite=Strict
cookie, puoi ridurre la protezione aLax
. - Nei casi in cui entrambi i cookie
Strict
eLax
vengono bloccati e i cookie vengono inviati a (o impostati da) un URL sicuro, puoi ridurre le protezioni aNone
.- Questa soluzione alternativa non andrà a buon fine se l'URL a cui stai inviando i cookie (o da cui
vengono impostati) non è sicuro. Questo perché
SameSite=None
richiede l'attributoSecure
per i cookie, il che significa che questi cookie non possono essere inviati o impostati su una connessione non sicura. In questo caso, non potrai accedere al cookie finché non avrai eseguito l'upgrade del sito a HTTPS. - Ricorda che si tratta di una situazione solo temporanea, in quanto i cookie di terze parti verranno ritirati completamente.
- Questa soluzione alternativa non andrà a buon fine se l'URL a cui stai inviando i cookie (o da cui
vengono impostati) non è sicuro. Questo perché
In che modo questo influisce sui miei cookie se non ho specificato un attributo SameSite
?
I cookie senza un attributo SameSite
vengono trattati come se fossero specificati SameSite=Lax
e lo stesso comportamento tra schemi viene applicato anche a questi cookie. Tieni presente che l'eccezione temporanea ai metodi non sicuri continua a essere valida. Per ulteriori informazioni, consulta la mitigazione di Lax + POST nelle SameSite
Domande frequenti di Chromium.
In che modo sono interessati i WebSocket?
Le connessioni WebSocket saranno comunque considerate "stesso sito" se offrono la stessa sicurezza della pagina.
Stesso sito:
wss://
connessione dahttps://
ws://
connessione dahttp://
Tra siti:
wss://
connessione dahttp://
ws://
connessione dahttps://
Foto di Julissa Capdevilla su Unsplash