Stesso sito schematico

La definizione di "stesso sito" 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 tra siti. Esegui l'upgrade a HTTPS per impostazione predefinita per evitare problemi, se possibile, o continua a leggere per i dettagli sui valori dell'attributo SameSite necessari.

Steven Bingler

Rowan Merewood

SameSite con schema modifica la definizione di un sito (web) dal solo dominio registrabile allo schema + dominio registrabile. Puoi trovare maggiori dettagli ed esempi in Informazioni su "stesso sito" e "stessa 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 priorità. Tuttavia, se ci sono casi in cui i visitatori del tuo sito passano da HTTP a HTTPS, alcuni di questi scenari comuni e il comportamento dei cookie SameSite associato sono descritti più avanti in questo articolo.

Puoi attivare queste modifiche per i test sia in Chrome che in Firefox.

• A partire da Chrome 86, attiva about://flags/#schemeful-same-site. Monitora i progressi nella pagina Stato di Chrome.
• A partire da Firefox 79, imposta network.cookie.sameSite.schemeful su true tramite about:config. Monitora i progressi utilizzando il problema di Bugzilla.

Uno dei motivi principali della modifica a SameSite=Lax come impostazione predefinita per i cookie era la protezione da richiesta cross-site (CSRF). Tuttavia, il traffico HTTP non sicuro offre ancora ai criminali informatici di rete l'opportunità di manomettere i cookie che verranno poi utilizzati nella versione HTTPS sicura del sito. La creazione di questo ulteriore limite tra siti tra gli schemi fornisce un'ulteriore difesa contro questi attacchi.

Scenari comuni tra schemi

Navigazione

La navigazione tra le versioni tra schemi di un sito web (ad esempio, il collegamento da http://site.example a https://site.example) in precedenza consentiva l'invio dei SameSite=Strict cookie. Ora viene trattata come una navigazione tra siti, il che significa che i cookie SameSite=Strict verranno bloccati.

Caricamento delle sottorisorse

Le modifiche apportate qui devono essere considerate solo una soluzione temporanea mentre lavori per eseguire l'upgrade a HTTPS completo.

Le sottorisorse includono immagini, iframe e richieste di rete effettuate con XHR o Fetch.

Il caricamento di una sottorisorsa tra schemi su una pagina in precedenza consentiva l'invio o l'impostazione dei cookie SameSite=Strict o SameSite=Lax. Ora viene trattata allo stesso modo di qualsiasi altra sottorisorsa di terze parti o tra siti, il che significa che tutti i cookie SameSite=Strict o SameSite=Lax verranno bloccati.

Inoltre, anche se il browser consente il caricamento delle risorse da schemi non sicuri su una pagina sicura, tutti i cookie verranno bloccati su queste richieste, poiché i cookie di terze parti o tra siti richiedono Secure.

Invio di un modulo

L'invio tra le versioni tra schemi di un sito web in precedenza consentiva l'invio dei cookie impostati con SameSite=Lax o SameSite=Strict. Ora viene trattato come un POST tra siti: è possibile inviare solo i cookie SameSite=None. Potresti riscontrare questo scenario sui siti che presentano la versione non sicura per impostazione predefinita, ma eseguono l'upgrade degli utenti alla versione sicura al momento dell'invio del modulo di accesso o di pagamento.

Come per le sottorisorse, se la richiesta proviene da un contesto sicuro (ad esempio HTTPS) a un contesto non sicuro (ad esempio HTTP), tutti i cookie verranno bloccati su queste richieste, poiché i cookie di terze parti o tra siti richiedono Secure.

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 Problemi in Strumenti per sviluppatori includerà i problemi di SameSite con schema. Potresti vedere i seguenti problemi evidenziati per il tuo sito.

Problemi di navigazione:

• "Esegui la migrazione completa a HTTPS per continuare a inviare 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 inviare 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 inviare i cookie alle sottorisorse dello stesso sito" o "Esegui la migrazione completa a HTTPS per continuare a consentire l'impostazione dei cookie da parte delle 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 inviare i cookie alle sottorisorse dello stesso sito" o "Esegui la migrazione completa a HTTPS per consentire l'impostazione dei cookie da parte delle sottorisorse dello stesso sito": avvisi che indicano che il cookie è stato bloccato. L'ultimo avviso può essere visualizzato anche durante l'invio di un modulo.

Per maggiori dettagli, consulta Suggerimenti per il test e il debug di SameSite con schema.

A partire da Firefox 79, con network.cookie.sameSite.schemeful impostato su true tramite about:config, la console visualizzerà un messaggio per i problemi di SameSite con schema. Potresti vedere quanto segue sul tuo sito:

• "Il cookie cookie_name verrà presto trattato come cookie tra siti rispetto a http://site.example/ perché lo schema non corrisponde."
• "Il cookie cookie_name è stato trattato come cookie tra siti rispetto a http://site.example/ perché lo schema non corrisponde."

Domande frequenti

Il mio sito è già completamente disponibile su HTTPS, perché vedo problemi in Strumenti per sviluppatori del browser?

È possibile che alcuni link e sottorisorse indirizzino ancora a URL non sicuri.

Un modo per risolvere questo problema è utilizzare HTTP Strict-Transport-Security (HSTS) e la includeSubDomain direttiva. Con HSTS + includeSubDomain, anche se una delle tue pagine include accidentalmente un link non sicuro, il browser utilizzerà automaticamente la versione sicura.

Cosa succede se non riesco a eseguire l'upgrade a HTTPS?

Sebbene ti consigliamo vivamente di eseguire l'upgrade completo del tuo sito a HTTPS per proteggere i tuoi utenti, se non riesci a farlo autonomamente ti suggeriamo di rivolgerti al tuo provider di hosting per verificare se può offrirti questa opzione. Se utilizzi l'hosting autonomo, allora Let's Encrypt fornisce una serie di strumenti per installare e configurare un certificato. Puoi anche valutare la possibilità di spostare il tuo sito dietro una CDN o un altro proxy in grado di fornire la connessione HTTPS.

Se non è ancora possibile, prova a ridurre la protezione SameSite sui cookie interessati.

• Nei casi in cui vengono bloccati solo i cookie SameSite=Strict, puoi ridurre la protezione a Lax.
• Nei casi in cui vengono bloccati sia i cookie Strict sia i cookie Lax e i cookie vengono inviati a (o impostati da) un URL sicuro, puoi ridurre le protezioni a None.
  • Questa soluzione alternativa non funzionerà se l'URL a cui invii i cookie (o da cui li imposti) non è sicuro. Questo perché SameSite=None richiede l'attributo Secure sui cookie, il che significa che questi cookie potrebbero non essere inviati o impostati tramite una connessione non sicura. In questo caso, non potrai accedere al cookie finché non esegui l'upgrade del tuo sito a HTTPS.
  • Ricorda che questa è solo una soluzione temporanea, poiché alla fine i cookie di terze parti verranno eliminati gradualmente.

In che modo influisce sui miei cookie se non ho specificato un attributo SameSite?

I cookie senza attributo SameSite vengono trattati come se avessero specificato SameSite=Lax e lo stesso comportamento tra schemi si applica anche a questi cookie Tieni presente che l'eccezione temporanea ai metodi non sicuri è ancora valida. Per maggiori informazioni, consulta la mitigazione Lax + POST nelle Domande frequenti su `SameSite` di Chromium SameSite .

In che modo sono interessati i WebSocket?

Le connessioni WebSocket verranno comunque considerate dello stesso sito se hanno la stessa sicurezza della pagina.

Stesso sito:

• Connessione wss:// da https://
• Connessione ws:// da http://

Tra siti:

• Connessione wss:// da http://
• Connessione ws:// da https://