Chrome, Firefox, Edge e altri ancora stanno modificando il loro comportamento predefinito in linea con la proposta IETF, Incrementally Better Cookies, in modo che:
- I cookie senza un attributo
SameSite
vengono trattati comeSameSite=Lax
, il che significa che il comportamento predefinito prevede di limitare i cookie a contesti proprietari solo. - I cookie per l'utilizzo tra siti devono specificare
SameSite=None; Secure
per consentire l'inclusione nel contesto di terze parti.
Se non lo hai già fatto, devi aggiornare gli attributi dei cookie di terze parti in modo che non vengano bloccati in futuro.
Casi d'uso dei cookie cross-site o di terze parti
Esistono diversi casi d'uso e pattern comuni in cui i cookie devono essere inviati in un contesto di terze parti. Se fornisci o dipendi da uno di questi casi d'uso, assicurati che tu o il provider stiate aggiornando i cookie per garantire il corretto funzionamento del servizio.
Contenuti all'interno di un <iframe>
I contenuti di un altro sito visualizzato in un <iframe>
sono inseriti in un contesto di terze parti. I casi d'uso standard includono:
- Contenuti incorporati condivisi da altri siti, ad esempio video, mappe, esempi di codice e post social.
- Widget di servizi esterni, ad esempio funzionalità di pagamenti, calendari, prenotazioni e prenotazioni.
- Widget come pulsanti social o servizi antifrode che creano
<iframes>
meno evidenti.
I cookie possono essere utilizzati qui, tra le altre cose, per mantenere lo stato della sessione, memorizzare preferenze generali, attivare statistiche o personalizzare i contenuti per gli utenti che dispongono di account esistenti.
Poiché il web è intrinsecamente componibile, gli elementi <iframes>
vengono utilizzati anche per incorporare
i contenuti visualizzati in un contesto di primo livello o proprietario. Tutti i cookie utilizzati dal sito visualizzato nell'iframe sono considerati cookie di terze parti. Se stai creando siti che vuoi che vengano incorporati da altri siti e hai bisogno dei cookie per farli funzionare, devi anche assicurarti che siano contrassegnati per l'utilizzo tra siti oppure di poter tornare indietro senza problemi.
Richieste "non sicure" tra i siti
"Non sicuro" potrebbe sembrare preoccupante, ma si riferisce a qualsiasi richiesta che potrebbe essere intesa a cambiare stato. Sul web si tratta principalmente di richieste POST. I cookie
contrassegnati come SameSite=Lax
vengono inviati durante navigazioni di primo livello sicure, ad esempio quando fai clic su
un link per passare a un altro sito. Tuttavia, qualcosa come l'invio di <form>
a
un altro sito usando il comando POST non include i cookie.
Questo pattern viene utilizzato per i siti che possono reindirizzare l'utente a un servizio remoto per eseguire alcune operazioni prima di tornare, ad esempio per reindirizzare l'utente a un provider di identità di terze parti. Prima che l'utente lasci il sito, viene impostato un cookie contenente un token monouso con l'aspettativa che questo token possa essere controllato nella richiesta restituita per mitigare gli attacchi CSRF (Cross Site Request Forgery). Se la richiesta di restituzione avviene tramite POST, dovrai contrassegnare i cookie come SameSite=None; Secure
.
Risorse remote
Qualsiasi risorsa remota su una pagina, ad esempio dai tag <img>
o dai tag <script>
, potrebbe basarsi sull'invio dei cookie con una richiesta. I casi d'uso più comuni includono
i pixel di monitoraggio e la personalizzazione dei contenuti.
Questo vale anche per le richieste inviate da JavaScript utilizzando fetch
o XMLHttpRequest
. Se fetch()
viene richiamata con l'opzione credentials: 'include'
, è probabile che tali richieste includano i cookie.
Per XMLHttpRequest
, i cookie previsti sono solitamente indicati con un
valore withCredentials
per true
. Questi cookie devono essere contrassegnati in modo appropriato per essere
inclusi nelle richieste cross-site.
Contenuti all'interno di una WebView
Un componente WebView in un'app specifica della piattaforma utilizza un browser. Gli sviluppatori devono verificare se le limitazioni o i problemi che interessano le loro app si applicano anche ai componenti WebView delle loro app.
Android consente inoltre alle sue app specifiche della piattaforma di impostare i cookie direttamente tramite
l'API CookieManager.
Come per i cookie impostati utilizzando intestazioni o JavaScript, valuta la possibilità di includere SameSite=None; Secure
se sono destinati all'utilizzo tra siti.
Come implementare SameSite
oggi stesso
Contrassegna tutti i cookie necessari solo in un contesto proprietario come SameSite=Lax
o SameSite=Strict
, a seconda delle tue esigenze. Se non contrassegni questi cookie e ti basi sul comportamento predefinito del browser per gestirli, questi potrebbero comportarsi in modo incoerente tra i vari browser e attivare potenzialmente avvisi della console per ogni cookie.
Set-Cookie: first_party_var=value; SameSite=Lax
Assicurati di contrassegnare tutti i cookie necessari in un contesto di terze parti come SameSite=None; Secure
. Entrambi gli attributi sono obbligatori. Se specifichi semplicemente
None
senza Secure
, il cookie verrà rifiutato. Per tenere conto delle differenze nelle implementazioni del browser, potresti dover utilizzare alcune delle strategie di mitigazione descritte in Gestire client incompatibili.
Set-Cookie: third_party_var=value; SameSite=None; Secure
Gestire client incompatibili
Poiché queste modifiche per includere None
e il comportamento predefinito di aggiornamento sono ancora relativamente nuove, i diversi browser le gestiscono in modi diversi. Puoi consultare la pagina degli aggiornamenti su chromium.org per un elenco dei problemi noti, ma questo elenco potrebbe non essere esaustivo.
Una possibile soluzione alternativa consiste nell'impostare ciascun cookie nel nuovo e nel vecchio stile:
Set-cookie: 3pcookie=value; SameSite=None; Secure
Set-cookie: 3pcookie-legacy=value; Secure
I browser che implementano il comportamento più recente impostano il cookie con il valore SameSite
. I browser che non implementano il nuovo comportamento ignorano questo valore e impostano il cookie 3pcookie-legacy
. Durante l'elaborazione dei cookie inclusi, il tuo sito deve prima verificare la presenza del nuovo stile di cookie e, poi, ricorrere al cookie precedente se non riesce a trovarne uno nuovo.
L'esempio seguente mostra come eseguire questa operazione in Node.js, utilizzando il framework Express e il relativo middleware cookie-parser:
const express = require('express');
const cp = require('cookie-parser');
const app = express();
app.use(cp());
app.get('/set', (req, res) => {
// Set the new style cookie
res.cookie('3pcookie', 'value', { sameSite: 'none', secure: true });
// And set the same value in the legacy cookie
res.cookie('3pcookie-legacy', 'value', { secure: true });
res.end();
});
app.get('/', (req, res) => {
let cookieVal = null;
if (req.cookies['3pcookie']) {
// check the new style cookie first
cookieVal = req.cookies['3pcookie'];
} else if (req.cookies['3pcookie-legacy']) {
// otherwise fall back to the legacy cookie
cookieVal = req.cookies['3pcookie-legacy'];
}
res.end();
});
app.listen(process.env.PORT);
Questo approccio richiede un ulteriore lavoro per impostare i cookie ridondanti e apportare modifiche al momento dell'impostazione e della lettura dei cookie. Tuttavia, dovrebbe riguardare tutti i browser indipendentemente dal loro comportamento e mantenere i cookie di terze parti in funzione.
In alternativa, puoi rilevare il client utilizzando la stringa dello user agent quando viene inviata un'intestazione Set-Cookie
. Fai riferimento all'elenco di client incompatibili e utilizza una libreria di rilevamento dello user agent appropriata per la tua piattaforma, ad esempio la libreria ua-parser-js su Node.js. Questo approccio richiede una sola modifica, ma lo sniffing dello user agent potrebbe non rilevare tutti gli utenti interessati.
Supporto per SameSite=None
in linguaggi, librerie e framework
La maggior parte delle lingue e delle librerie supporta l'attributo SameSite
per i cookie. Tuttavia, poiché l'aggiunta di SameSite=None
è ancora relativamente recente, potresti dover aggirare alcuni comportamenti standard per ora.
Questi comportamenti sono documentati nel repository di esempi di SameSite
su GitHub.
Richiesta di aiuto
I cookie vengono utilizzati ovunque sul Web ed è raro che un team di sviluppo sia a conoscenza completa dei luoghi in cui il proprio sito li imposta e li utilizza, soprattutto nei casi d'uso tra siti. Quando si verifica un problema, potrebbe essere la prima volta che viene rilevato, quindi non esitare a contattarci:
- Segnala un problema nel repository di esempi di
SameSite
su GitHub. - Poni una domanda nel tag"samesite" su StackOverflow.
- Per problemi relativi al comportamento di Chromium, segnala un bug nel Issue Tracker di Chromium.
- Segui i progressi di Chrome nella pagina degli aggiornamenti di
SameSite
.