Come un solo attributo mancante decide tra cookie di sessione e cookie persistente

Qual è la differenza tra un cookie di sessione e un cookie persistente?

Tutta la differenza tra cookie di sessione e cookie persistente sta in un attributo: un cookie persistente ha una data Expires o un Max-Age in secondi, un cookie di sessione non ha né l'uno né l'altro. La RFC 6265, lo standard attuale sui cookie, dice che un cookie senza nessuno dei due attributi viene conservato finché "the current session is over" (come definito dallo user agent). Un cookie con uno dei due attributi viene conservato fino allo scadere di quel termine, a meno che il browser o l'utente lo cancellino prima.

Set-Cookie: sid=31d4d96e407aad42; Path=/; Secure; HttpOnly
Set-Cookie: lang=en-US; Max-Age=2592000; Path=/

La prima riga imposta un cookie di sessione. La seconda imposta un cookie persistente che dura 2.592.000 secondi, cioè 30 giorni. Il nome del cookie non c'entra. Un cookie chiamato session_id con un Max-Age è persistente, mentre un cookie chiamato remember_me senza scadenza è un cookie di sessione.

Come decide il browser che tipo di cookie ha ricevuto?

Il browser lo decide leggendo gli attributi in ordine, secondo l'algoritmo di memorizzazione della sezione 5.3 della RFC 6265. Se il cookie ha un Max-Age, il browser imposta il persistent-flag del cookie su vero e usa Max-Age per la scadenza. Altrimenti, se ha un Expires, il flag è vero e la scadenza viene da Expires. In tutti gli altri casi il flag è falso e la scadenza viene impostata su "the latest representable date".

Quindi, secondo la specifica, un cookie di sessione ha la data di scadenza più lontana possibile, e a farlo rimuovere è solo il persistent-flag falso. La stessa sezione dice: "When 'the current session is over' (as defined by the user agent), the user agent MUST remove from the cookie store all cookies with the persistent-flag set to false."

Altre due regole contano nella pratica:

• Max-Age vince su Expires. Sezione 4.1.2.2: "If a cookie has both the Max-Age and the Expires attribute, the Max-Age attribute has precedence and controls the expiration date of the cookie."
• Zero cancella. Secondo la sezione 5.2.2, un Max-Age pari o inferiore a 0 imposta la scadenza su "the earliest representable date and time", quindi il cookie viene rimosso subito. Inviare Max-Age=0 è il modo standard per cancellare un cookie dal server.

Le due pagine di MDN sui cookie non concordano su quale orologio usi la data di Expires. La guida ai cookie HTTP dice che le date Expires sono "relative to the client the cookie is being set on", quindi un server con un orario diverso può causare errori. Il riferimento a Set-Cookie dice invece che il server imposta Expires "with a value relative to its own internal clock", e che Firefox e i browser basati su Chromium correggono la differenza di orologio usando l'header Date, mentre la specifica "does not indicate if/how the value should be corrected by the recipient." Il consiglio della guida vale comunque: Max-Age è "less error-prone", perché conta i secondi dal momento in cui il browser riceve il cookie.

Quando finisce davvero una sessione?

Nessuno standard dice quando finisce una sessione, ed è per questo che i cookie di sessione non si comportano come suggerisce il loro nome. La RFC 6265 lo lascia al browser con la formula "as defined by the user agent", che compare sia nella sezione sugli attributi sia in quella sulla memorizzazione.

Le due pagine di MDN descrivono il risultato da lati opposti. Il riferimento a Set-Cookie dice che una sessione "finishes when the client shuts down, after which the session cookie is removed", poi avverte che i browser con una funzione di ripristino della sessione ripristinano anche i cookie di sessione, "as if the browser was never closed." La guida ai cookie HTTP va oltre: "The browser defines when the 'current session' ends, and some browsers use session restoring when restarting. This can cause session cookies to last indefinitely."

Con il ripristino della sessione attivo, un cookie di sessione può sopravvivere a un cookie persistente con scadenza a una settimana. Il codice che considera il cookie di sessione una garanzia di logout dipende da un'impostazione del browser che non può vedere, quindi fai scadere l'autenticazione anche lato server.

Un cookie di sessione non ha nemmeno nulla a che fare con una sessione in ambito analytics. Google Analytics 4 salva lo stato della sessione in un cookie chiamato _ga_<container-id>, che il suo centro assistenza elenca con una scadenza predefinita di 2 anni e la descrizione "Used to persist session state." La sessione analytics è una finestra di tempo calcolata dallo strumento, spiegata in cosa conta come sessione. Il cookie che la ricorda è persistente.

Quanto può durare un cookie persistente?

Un cookie persistente può durare fino a 400 giorni in Chrome e nella bozza che sostituirà la RFC 6265. La RFC 6265 non fissava alcun limite massimo. Il suo successore, draft-ietf-httpbis-rfc6265bis-22 del 1 dicembre 2025, che il datatracker dell'IETF mostra nella coda del RFC Editor, aggiunge la sezione 5.5: il browser "MUST limit the maximum age of the cookie" (deve limitare la durata massima del cookie), e "The limit SHOULD NOT be greater than 400 days (34560000 seconds) in the future" (il limite non dovrebbe superare i 400 giorni, cioè 34560000 secondi, nel futuro). Un valore di Expires o Max-Age oltre il limite "MUST be reduced to the limit" (deve essere ridotto al limite).

Chrome applica già questo tetto. Il blog Chrome for Developers lo dichiara così: "As of Chrome release M104 (August 2022) cookies can no longer set an expiration date more than 400 days in the future" (a partire da Chrome M104, agosto 2022, i cookie non possono più impostare una data di scadenza oltre i 400 giorni nel futuro). Questo mette in conflitto due numeri pubblicati. Google Analytics documenta valori predefiniti di 2 anni per _ga e _ga_<container-id>, e Chrome, anch'esso di Google, riduce a 400 giorni qualsiasi data simile nel momento in cui il cookie viene salvato.

Safari fissa un limite molto più basso per un tipo di cookie. L'annuncio di Intelligent Tracking Prevention 2.1 di WebKit, del 21 febbraio 2019, dice: "All persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry" (tutti i cookie persistenti lato client, cioè quelli creati tramite document.cookie, sono limitati a una scadenza di sette giorni). Lo stesso articolo aggiunge: "Session cookies are not affected, they remain session cookies" (i cookie di sessione non sono interessati e restano cookie di sessione). I cookie impostati dall'header Set-Cookie di un server restano fuori da questa regola. Tutte le regole di Safari le trovi in come funziona il limite di 7 giorni dei cookie in Safari.

La RFC 6265 chiede inoltre ai server di darsi un limite. La sezione 7.3 dice che i server "SHOULD promote user privacy by selecting reasonable cookie expiration periods based on the purpose of the cookie" (dovrebbero tutelare la privacy dell'utente scegliendo periodi di scadenza ragionevoli in base allo scopo del cookie), e porta un esempio che confonde il vocabolario: "a typical session identifier might reasonably be set to expire in two weeks" (un tipico identificatore di sessione può ragionevolmente essere impostato per scadere dopo due settimane). Un identificatore di sessione, insomma, spesso vive in un cookie persistente.

I cookie di sessione e i cookie persistenti richiedono il consenso?

Secondo il diritto dell'UE, nessuno dei due tipi è esente dal consenso per via della sua durata, ed entrambi sono esenti solo quando sono strettamente necessari per un servizio richiesto dall'utente. Il Parere 04/2012 del Gruppo di lavoro Articolo 29 sull'esenzione dal consenso per i cookie, adottato il 7 giugno 2012, definisce i due termini: un cookie di sessione "is automatically deleted when the user closes his browser" (viene cancellato automaticamente quando l'utente chiude il browser), e un cookie persistente "remains stored in the user's terminal device until it reaches a defined expiration date (which can be minutes, days or several years in the future)" (resta memorizzato nel dispositivo terminale dell'utente fino a una data di scadenza definita, che può essere tra minuti, giorni o diversi anni).

Il parere tratta poi la durata come un indizio, non come un criterio di verifica. Afferma che "'first party' session cookies are far more likely to be exempted from consent than 'third party' persistent cookies" (è molto più probabile che i cookie di sessione "di prima parte" siano esentati dal consenso rispetto ai cookie persistenti "di terze parti"), e nello stesso paragrafo che "The risk to data protection comes from the purpose(s) of processing rather than the information contained within the cookie" (il rischio per la protezione dei dati deriva dalle finalità del trattamento, più che dalle informazioni contenute nel cookie). L'esempio più chiaro è il login. I cookie di autenticazione che durano quanto la sessione sono esenti, ma "Persistent login cookies which store an authentication token across browser sessions are not exempted" (i cookie di login persistenti, che conservano un token di autenticazione tra una sessione e l'altra del browser, non sono esenti), e una casella "remember me (uses cookies)" (ricordami, usa i cookie) è indicata come un modo adeguato per ottenere il consenso.

Le autorità nazionali aggiungono dei numeri. La CNIL francese, nelle sue linee guida sugli strumenti di misurazione dell'audience, permette a questi tracker di saltare il consenso solo se la loro durata è limitata a un periodo "comme c'est le cas d'une durée de treize mois" (13 mesi, per esempio), non è "prorogée automatiquement lors des nouvelles visites" (prorogata automaticamente a ogni nuova visita), e i dati raccolti vengono conservati al massimo "vingt-cinq mois" (25 mesi). Un cookie di analytics che azzera la scadenza a ogni visita non rispetta la seconda condizione, per quanto breve sia la sua durata.

Per la tabella dei cookie in una informativa sulla privacy, indica la durata di ogni cookie così com'è davvero impostata, "sessione" oppure una durata, accanto alla sua finalità e al fatto che sia di prima o di terza parte. Le stesse domande valgono per i dati conservati nello storage del browser, di cui si occupa la pagina su local storage e cookie a confronto.

Domande frequenti

Come faccio a rendere un cookie un cookie di sessione?

Ometti sia l'attributo Expires sia Max-Age quando lo imposti. Il browser tiene allora il cookie fino alla fine della sessione, secondo la definizione che ne dà il browser. La pagina MDN su document.cookie riporta la stessa regola per i cookie impostati da script: se nessuno dei due è specificato, il cookie scade alla fine della sessione.

I cookie di sessione vengono cancellati quando chiudo una scheda?

No. Chiudere una scheda non termina la sessione del browser. I cookie di sessione vengono rimossi quando il browser si chiude, a meno che il ripristino della sessione non li riporti indietro.

Quale prevale se un cookie ha sia Expires sia Max-Age?

Prevale Max-Age. La RFC 6265, sezione 4.1.2.2, dice che Max-Age "has precedence and controls the expiration date of the cookie" (ha la precedenza e controlla la data di scadenza del cookie). MDN aggiunge che Max-Age è meno soggetto a errori, perché una data Expires dipende da orologi che possono non essere allineati.

Come si elimina un cookie persistente?

Imposta di nuovo lo stesso cookie, con lo stesso nome, dominio e percorso, e con un Max-Age pari a 0 oppure una data Expires nel passato. La RFC 6265 tratta un Max-Age pari o inferiore a zero come la prima data rappresentabile, quindi il browser rimuove subito il cookie.

I cookie di sessione sono più privati dei cookie persistenti?

I cookie di sessione hanno una vita più breve per progetto, e questo limita per quanto tempo possono collegare tra loro le visite. Il Gruppo di lavoro Articolo 29 ha comunque giudicato i cookie in base alla finalità: un cookie di sessione usato per il tracciamento richiede il consenso, mentre un cookie persistente può essere esente quando l'utente ha chiesto ciò che fa.

La navigazione privata trasforma i cookie persistenti in cookie di sessione?

In pratica sì. La RFC 6265, sezione 7.2, dice che un browser che offre di impedire l'archiviazione persistente "MUST treat all received cookies as if the persistent-flag were set to false" (deve trattare tutti i cookie ricevuti come se il flag persistente fosse impostato su falso), e cita la navigazione privata come forma comune di questa impostazione. Ogni cookie sparisce quando la sessione privata si chiude.

Un cookie di sessione è la stessa cosa di una sessione in Google Analytics?

No. La sessione di analytics è una finestra temporale calcolata dallo strumento, e il cookie che la ricorda è persistente. Google Analytics 4 salva lo stato della sessione in _ga_<container-id>, che il suo centro assistenza elenca con una scadenza predefinita di 2 anni.

Quanto può durare un cookie persistente in Chrome?

Fino a 400 giorni. Da Chrome M104, nell'agosto 2022, i cookie non possono più impostare una data di scadenza oltre i 400 giorni nel futuro, quindi un valore di Expires o Max-Age più lungo viene tagliato a quel limite. La bozza rfc6265bis fissa lo stesso tetto.

I cookie di sessione sopravvivono al riavvio del browser?

Non secondo la specifica, ma spesso nella pratica sì. La RFC 6265 lascia al browser decidere quando finisce la sessione, e i browser con ripristino della sessione riportano indietro i cookie di sessione come se il browser non fosse mai stato chiuso. MDN avverte che così possono durare indefinitamente.

Un cookie di login "ricordami" richiede il consenso nell'UE?

Sì. Il Parere 04/2012 del Gruppo di lavoro Articolo 29 dice che i cookie di login persistenti, che conservano un token di autenticazione tra una sessione e l'altra del browser, non sono esenti, e indica una casella "remember me (uses cookies)" come un modo per ottenere il consenso. I cookie di autenticazione che durano solo quanto la sessione sono esenti.