Chrome Firefox Perimetrale e altri stanno modificando il comportamento predefinito in linea con IETF proposta, Cookie in modo incrementale in modo che:
- I cookie senza un attributo
SameSite
vengono trattati comeSameSite=Lax
, vale a dire che il comportamento predefinito è limitare i cookie ai cookie proprietari solo. - I cookie per l'utilizzo tra siti devono specificare
SameSite=None; Secure
per consentire l'inclusione in un contesto di terze parti.
Se non l'hai già fatto, devi aggiornare gli attributi per il tuo cookie di terze parti, in modo che non vengano bloccati in futuro.
Casi d'uso dei cookie in più siti 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 ti basi su uno di questi usi casi, accertati che tu o il fornitore stiate aggiornando i cookie per per mantenere il corretto funzionamento del servizio.
Contenuti all'interno di un <iframe>
I contenuti di un altro sito visualizzati in un <iframe>
appartengono a una terza parte
contesto. I casi d'uso standard includono:
- Contenuti incorporati condivisi da altri siti, come video, mappe, esempi di codice e post sui social media.
- Widget di servizi esterni come pagamenti, calendari, prenotazioni e funzionalità di prenotazione.
- Widget come pulsanti di social network o servizi antifrode che creano contenuti meno evidenti
<iframes>
.
I cookie possono essere usati qui, tra le altre cose, per mantenere lo stato della sessione, preferenze generali, attivare le statistiche o personalizzare i contenuti per gli utenti con account esistenti.
Poiché il web è intrinsecamente componibile, gli asset <iframes>
vengono utilizzati anche per incorporare
contenuti visualizzati in un contesto di primo livello o proprietario. Eventuali cookie del sito
visualizzati nell'iframe sono considerati cookie di terze parti. Se
creando siti che si desidera vengano incorporati in altri siti e necessitano di cookie per l'inserimento.
devi anche assicurarti che siano contrassegnate per l'utilizzo su più siti o che tu
possono ripiegare con eleganza senza di loro.
"Non sicuro" Richieste tra siti
"Non sicuro" in questo contesto potrebbe sembrare preoccupante, ma si riferisce a qualsiasi richiesta che
destinato a cambiare stato. Sul Web, si tratta principalmente di richieste POST. Cookie
contrassegnate come SameSite=Lax
vengono inviate per navigazioni di primo livello sicure, ad esempio facendo clic su
per andare a un altro sito. Tuttavia, un invio di <form>
a
un altro sito che utilizza POST non includa i cookie.
Questo pattern viene utilizzato per i siti che possono reindirizzare l'utente a un server
eseguire alcune operazioni prima di restituirlo, ad esempio il reindirizzamento a
un provider di identità di terze parti. Prima che l'utente abbandoni il sito, un cookie viene
un set contenente un token monouso con l'aspettativa che possa essere
ha controllato la richiesta restituita per ridurre
Falso richiesta cross-site (CSRF)
attacchi informatici. Se la richiesta di ritorno arriva tramite POST, dovrai contrassegnare il
cookie come SameSite=None; Secure
.
Risorse remote
Qualsiasi risorsa remota su una pagina, ad esempio dai tag <img>
o <script>
,
potrebbe basarsi sull'invio dei cookie con una richiesta. I casi d'uso più comuni includono
pixel di monitoraggio e personalizzazione dei contenuti.
Questo vale anche per le richieste inviate da JavaScript utilizzando fetch
o
XMLHttpRequest
. Se fetch()
viene chiamato con il
opzione credentials: 'include'
,
è probabile che queste richieste includano i cookie.
Per XMLHttpRequest
, i cookie previsti sono generalmente indicati da un
Valore withCredentials
da true
. Questi cookie devono essere contrassegnati in modo appropriato per essere inclusi in
richieste tra siti.
Contenuti in una WebView
Un componente WebView in un'app specifica della piattaforma è basato su un browser. Gli sviluppatori devono verificare se le limitazioni o i problemi che interessano le loro app si applicano anche i componenti WebView dell'app.
Android consente inoltre alle app specifiche della piattaforma di impostare i cookie direttamente utilizzando
API CookieManager.
Come per i cookie impostati utilizzando intestazioni o JavaScript, valuta la possibilità di includere
SameSite=None; Secure
se sono destinati all'uso su più 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 si affidano al comportamento predefinito del browser per gestirle, possono comportarsi
in modo incoerente tra i 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
None
senza Secure
, il cookie verrà rifiutato. Per tenere conto delle differenze
nelle implementazioni del browser, potrebbe essere necessario utilizzare alcune
strategie descritte in Gestire clienti incompatibili.
Set-Cookie: third_party_var=value; SameSite=None; Secure
Gestisce client non compatibili
Poiché queste modifiche per includere None
e il comportamento predefinito dell'aggiornamento sono ancora valide
relativamente nuovi, ma browser diversi li gestiscono in modi diversi. Puoi segnalare
alla pagina degli aggiornamenti su chromium.org
per un elenco di problemi noti, che però potrebbe non essere esaustivo.
Una possibile soluzione consiste nell'impostare ciascun cookie sia nel nuovo che 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 SameSite
valore. I browser che non implementano il nuovo comportamento ignorano quel valore e impostano
il cookie 3pcookie-legacy
. Durante l'elaborazione dei cookie inclusi, il tuo sito dovrebbe
verifica innanzitutto la presenza del nuovo stile di cookie, poi torna a
il cookie precedente se non ne trova uno nuovo.
L'esempio seguente mostra come eseguire questa operazione in Node.js, utilizzando il metodo Framework Express e relativi 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 lavoro supplementare per impostare cookie ridondanti e per fare in modo che le modifiche al momento dell'impostazione e della lettura del cookie. Tuttavia, coprono tutti i browser indipendentemente dal loro comportamento e conservano i cookie di terze parti della funzionalità.
In alternativa, puoi rilevare il client utilizzando la stringa dello user agent quando
Intestazione Set-Cookie
inviata. Consulta le
elenco di client non compatibili,
e utilizzare una libreria di rilevamento dello user agent adeguata per la tua piattaforma, ad esempio
Ad esempio, la libreria ua-parser-js
su Node.js. Questo approccio richiede solo una modifica, ma lo user agent
lo sniffing 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
cookie. Tuttavia, poiché l'aggiunta di SameSite=None
è ancora relativamente
recente, potrebbe essere necessario aggirare alcuni comportamenti standard per il momento.
Questi comportamenti sono documentati
Repository di esempi di SameSite
su GitHub.
Richiesta di aiuto
I cookie vengono utilizzati ovunque sul web ed è raro che un team di sviluppo di avere una conoscenza completa dei punti in cui il sito inserisce e li utilizza, in particolare nei casi d'uso cross-site. Quando si verifica un problema, potrebbe essere la prima volta se lo hanno riscontrato, non esitare a contattarmi:
- Segnala un problema nel
Repository di esempi di
SameSite
su GitHub. - Fai una domanda nel "samesite" su StackOverflow.
- Per problemi relativi al comportamento di Chromium, segnala un bug nel Issue Tracker di Chromium.
- Segui i progressi di Chrome sul
Pagina degli aggiornamenti di
SameSite
.