Cosa si rompe davvero con SameSite Lax, Strict e None

Che differenza c'è tra SameSite Lax, Strict e None?

I browser leggono SameSite Lax, Strict e None come tre risposte alla stessa domanda: quali richieste cross-site possono portare con sé questo cookie. L'RFC 6265bis le riassume tutte e tre in un solo paragrafo della sezione 4.1.2.7: "Se il valore dell'attributo 'SameSite' è 'Strict', il cookie verrà inviato solo insieme alle richieste 'same-site'. Se il valore è 'Lax', il cookie verrà inviato con le richieste same-site e con le navigazioni cross-site di primo livello, come descritto nella sezione 5.6.7.1. Se il valore è 'None', il cookie verrà inviato con le richieste same-site e cross-site."

La bozza in vigore è draft-ietf-httpbis-rfc6265bis-22, datata 1° dicembre 2025, curata da Bingler, West e Wilander e marcata "Obsoletes: 6265 (if approved)". L'attributo limita l'ambito per sito e non per origine, quindi https://www.site.example e https://api.site.example sono lo stesso sito. Se due host condividano o meno un sito lo decide la public suffix list, non il solo dominio registrabile.

Cosa permette Lax che Strict non permette?

Lax permette esattamente una classe di richieste in più: una navigazione cross-site di primo livello che usa un metodo HTTP sicuro. L'RFC enuncia l'eccezione e il suo scopo insieme, definendo Lax "un meccanismo drop-in che attenua il rischio di attacchi CSRF" e che "invia i cookie same-site insieme alle richieste cross-site se e solo se sono navigazioni di primo livello che usano un metodo HTTP 'sicuro' (nel senso di [HTTP])."

MDN trasforma questa regola nel test che applichi nella pratica. Una navigazione di primo livello "significa in sostanza che la richiesta fa cambiare l'URL mostrato nella barra degli indirizzi del browser". Ne fanno parte un link cliccato, un'assegnazione a document.location e l'invio di un <form>. Restano fuori "le richieste fatte con l'API fetch(), le richieste di sottorisorse da elementi <img> o <script> e le navigazioni dentro elementi <iframe>." La metà sul metodo sicuro "esclude POST, PUT e DELETE."

L'RFC è onesta su ciò che Lax non ti dà. "L'applicazione di Lax offre una ragionevole difesa in profondità contro gli attacchi CSRF che si basano su metodi HTTP non sicuri (come POST), ma non offre una difesa robusta contro il CSRF come categoria generale di attacco", perché "Gli attaccanti possono comunque aprire nuove finestre o innescare navigazioni di primo livello per creare una richiesta 'same-site'".

Qual è il default documentato di Chrome per SameSite?

Chrome tratta un cookie senza attributo SameSite come Lax e documenta una eccezione voluta. Il riferimento di Google enuncia la regola: "Se invii un cookie senza specificarne l'attributo SameSite, il browser lo tratta come se fosse impostato su SameSite=Lax." La stessa pagina aggiunge l'eccezione in un riquadro di avvertenza: "Il comportamento predefinito di Chrome è leggermente più permissivo di un SameSite=Lax esplicito, perché consente ai siti di inviare alcuni cookie nelle richieste POST di primo livello. Per i dettagli, vedi l'annuncio su blink-dev. Questa è pensata come misura di mitigazione temporanea."

Quella pagina riporta come ultimo aggiornamento il 7 maggio 2019 e una tabella di supporto dei browser che indica Chrome 80 ed Edge 86 per il cambio di default, Firefox dietro un flag e Safari non supportato. Da allora l'IETF ha formalizzato l'eccezione che Chrome definisce temporanea. L'RFC 6265bis la chiama "Lax-allowing-unsafe" e la specifica così: gli user agent "POSSONO applicare l'enforcement 'Lax-allowing-unsafe' solo ai cookie che non hanno specificato esplicitamente un attributo SameSite", "DOVREBBERO limitare l'enforcement ai cookie creati di recente" e "L'esperienza di diffusione ha mostrato che un'età del cookie di 2 minuti o meno è un limite ragionevole." MDN riporta lo stesso numero dal lato dei browser: con un Lax di default, "i cookie sono inclusi anche nelle richieste POST, purché siano stati impostati al massimo due minuti prima della richiesta."

Ne seguono due conseguenze, e sorprendono entrambe molte persone. Scrivere SameSite=Lax in modo esplicito è più restrittivo che non scrivere nulla, perché l'RFC applica Lax-allowing-unsafe solo ai cookie il cui flag è "Default" per assenza. Inoltre "Lax-allowing-unsafe non è un valore distinto dell'attributo SameSite", quindi non esiste una stringa da inviare per richiederlo.

La specifica gestisce allo stesso modo anche un errore di battitura. "Se il valore dell'attributo 'SameSite' è diverso da queste tre parole chiave note, il valore dell'attributo sarà soggetto a una modalità di enforcement predefinita equivalente a 'Lax'." Un cookie inviato con SameSite=Laxx non viene rifiutato, ma trattato in silenzio come se non fosse impostato.

Perché SameSite=None deve avere Secure?

Un cookie che dichiara SameSite=None senza Secure viene scartato, e l'RFC lo mette nell'algoritmo di memorizzazione e non in un semplice consiglio. Il passo 19 della sezione 5.7 recita: "Se il 'same-site-flag' del cookie è 'None', interrompi questo algoritmo e ignora del tutto il cookie, a meno che il secure-only-flag del cookie sia true."

Il riferimento di Google dice lo stesso agli sviluppatori: "Quando crei cookie cross-site con SameSite=None, devi impostarli anche come Secure perché il browser li accetti", e fornisce l'header completo:

Set-Cookie: widget_session=abc123; SameSite=None; Secure

La formulazione di MDN è altrettanto netta: per None, "Quando usi questo valore deve essere impostato anche l'attributo Secure." Nella console non compare nessun avviso che la maggior parte delle persone riconoscerebbe come tale, perché il cookie semplicemente non viene mai memorizzato. Se un'integrazione cross-site funziona sulla tua macchina e fallisce in produzione, controlla per prima cosa se la risposta ha impostato SameSite=None su HTTP semplice.

Partitioned si aggiunge a questo, non lo sostituisce. I browser accettano quell'attributo solo insieme a SameSite=None, come spieghiamo in come i cookie partizionati CHIPS danno a ogni sito il suo contenitore.

Cosa si rompe in ogni modalità?

L'RFC illustra il problema di Strict con uno scenario, non con una regola. Un utente che legge la posta su https://site.example clicca un link verso https://projects.example/secret/project: "se https://projects.example ha marcato i propri cookie di sessione come SameSite=Strict, questa navigazione cross-site non li invierà insieme alla richiesta. https://projects.example mostrerà un errore 404 per evitare di divulgare informazioni riservate, e l'utente sarà piuttosto confuso." Con Strict, ogni link in entrata da ricerca, email, chat e social sembra una visita da utente non loggato al primo caricamento.

La soluzione indicata prevede due cookie invece di uno, "uno che concede concettualmente l'accesso in 'lettura', l'altro l'accesso in 'scrittura'. Il secondo potrebbe essere marcato come SameSite=Strict, e la sua assenza richiederebbe una nuova autenticazione prima di eseguire qualsiasi azione non idempotente. Il primo potrebbe essere marcato come SameSite=Lax."

Lax rompe un insieme più ristretto di cose, e l'RFC cita il caso più evidente: "il passaggio finale di un flusso di login può comportare una richiesta POST cross-site di primo livello verso un endpoint che si aspetta un cookie creato di recente, contenente informazioni transazionali necessarie per completare il login in sicurezza." Con Lax esplicito, quel cookie viene escluso a causa del metodo, "con il risultato di un fallimento irrecuperabile dell'intero flusso di login." Il single sign-on e i ritorni dai pagamenti falliscono nello stesso modo.

None non rompe nulla per regola e tutto per policy. L'RFC individua i casi in cui serve, "i contenuti pensati per essere incorporati in contesti cross-site (widget di social network o servizi di commento, ad esempio) non avranno accesso ai cookie same-site. I cookie necessari in queste situazioni dovrebbero essere marcati con SameSite=None", e aggiunge che "alcune forme di Single-Sign-On potrebbero richiedere un'autenticazione basata su cookie in un contesto cross-site". Un cookie SameSite=None; Secure è un cookie di terze parti in tutto ciò che conta per i controlli sulla privacy di un browser, quindi eredita ogni restrizione che quei controlli applicano. Questa eredità è il cuore del discorso in solo il dominio decide tra cookie di prima parte e di terze parti e in cosa limita davvero il limite di 7 giorni dei cookie in Safari.

Una risposta cross-site può impostare un cookie Lax o Strict?

No, e questa regola è separata dall'invio. La sezione 4.1.2.7 stabilisce che "L'attributo 'SameSite' influisce sia sulla creazione sia sull'invio dei cookie. I cookie che dichiarano 'SameSite=Lax' o 'SameSite=Strict' non possono essere impostati nelle risposte a richieste di sottorisorse cross-site o a navigazioni annidate cross-site. Possono essere impostati insieme a qualsiasi navigazione di primo livello, cross-site o meno."

Quindi un widget incorporato in un <iframe> sulla pagina di qualcun altro non può scrivere affatto un cookie Lax, qualunque sia la sua intenzione. L'unico cookie che può scrivere è SameSite=None; Secure. Gli script di analytics serviti da un dominio condiviso del fornitore ci sbattono contro di continuo, ed è uno dei motivi per cui l'hosting degli script in first party e la decorazione dei link che Apple prende di mira sono passati al centro della progettazione delle misurazioni.

Domande frequenti

Quale valore SameSite dovrebbe usare un cookie di sessione?

Lax per un cookie di sessione che deve sopravvivere a un link in entrata, dato che l'RFC definisce Lax un "meccanismo sostitutivo immediato che riduce il rischio di attacchi CSRF". Strict per tutto ciò che protegge un'azione che modifica lo stato, seguendo lo schema a due cookie dell'RFC, dove l'"assenza" della metà Strict "richiederebbe una nuova autenticazione prima di eseguire qualsiasi azione non idempotente."

Omettere SameSite equivale a scrivere SameSite=Lax?

Non in Chrome. Google documenta il comportamento predefinito come più permissivo: "permette ai siti di inviare alcuni cookie nelle richieste POST di primo livello." L'RFC 6265bis limita questo comportamento di tipo Lax-allowing-unsafe ai "cookie che non hanno specificato esplicitamente un attributo SameSite", con un limite di età consigliato di "2 minuti o meno". Scrivere l'attributo esplicitamente dà un comportamento più restrittivo che lasciarlo fuori.

SameSite=None richiede HTTPS?

Sì, in modo indiretto, perché richiede Secure e i cookie Secure sono limitati ai protocolli sicuri. Il passaggio 19 dell'RFC 6265bis scarta del tutto il cookie: va ignorato "a meno che il secure-only-flag del cookie sia true."

SameSite basta da solo a fermare il CSRF?

No. L'RFC dice che Lax "non offre una difesa robusta contro il CSRF come categoria generale di attacco" e invita gli sviluppatori a "mitigare in modo più completo il CSRF tramite un meccanismo di gestione delle sessioni". Le linee guida di Google aggiungono che "né Strict né Lax sono una soluzione completa per la sicurezza del tuo sito."

Cosa succede se invio un valore SameSite non valido?

Viene trattato come se non avessi inviato nulla. Secondo la sezione 4.1.2.7, un valore "diverso da queste tre parole chiave note" ottiene "una modalità di applicazione predefinita equivalente a 'Lax'", e l'algoritmo di memorizzazione imposta il same-site-flag del cookie su "Default". Le maiuscole non contano, perché l'RFC confronta "None", "Strict" e "Lax" senza distinguere tra maiuscole e minuscole.

SameSite si decide per dominio o per sito?

Per sito, che è un concetto più ampio dell'origine e più stretto del dominio. I sottodomini dello stesso sito registrabile sono same-site tra loro, e il riferimento di Google indica il confine che coglie molti di sorpresa: la public suffix list "non dipende solo dai domini di primo livello come .com, ma può includere anche servizi come github.io", quindi your-project.github.io e my-project.github.io sono siti separati.

Perché i link da email o ricerca si rompono con SameSite=Strict?

L'RFC descrive proprio questo caso. Un utente che legge la posta clicca un link verso un sito con cookie di sessione SameSite=Strict, e la navigazione cross-site non porta con sé quei cookie. La destinazione mostra un 404 per evitare di divulgare dati, e l'utente vede quella che sembra una pagina da non loggato al primo caricamento. La soluzione dell'RFC sono due cookie invece di uno, con solo il cookie di accesso in scrittura marcato Strict e quello di accesso in lettura marcato Lax.

Perché un flusso di login fallisce con SameSite=Lax?

Alcuni flussi di login si chiudono con una POST cross-site di primo livello verso un endpoint di callback che si aspetta un cookie creato di recente con informazioni transazionali. Un cookie SameSite=Lax esplicito viene escluso da quella richiesta perché POST non è un metodo sicuro, e l'RFC lo descrive come "un fallimento irrecuperabile dell'intero flusso di login." Il single sign-on e i ritorni dai pagamenti falliscono per lo stesso motivo.

Un widget in un iframe cross-site può impostare un cookie Lax?

No. La sezione 4.1.2.7 stabilisce che i cookie con SameSite=Lax o SameSite=Strict non possono essere impostati nelle risposte a richieste di sottorisorse cross-site o a navigazioni annidate cross-site, il che include un iframe incorporato nella pagina di qualcun altro. L'unico cookie che un widget del genere può scrivere è SameSite=None con Secure.

Che rapporto c'è tra l'attributo Partitioned e SameSite=None?

Partitioned si aggiunge a SameSite=None, non lo sostituisce. I browser accettano l'attributo Partitioned solo insieme a SameSite=None, ed è così che CHIPS dà a ogni sito il proprio contenitore di cookie mantenendo i requisiti di None e Secure.