Dimensione, scadenza, accesso e legge: local storage e cookie a confronto

Qual è la differenza tra local storage e cookie?

La differenza di fondo nel confronto tra local storage e cookie riguarda la destinazione dei dati. Il browser allega i cookie alle richieste HTTP inviate al server, mentre il local storage resta dentro il browser finché uno script non lo legge e lo manda da qualche parte. Tutto il resto ne discende. Lo standard HTML del WHATWG, che definisce localStorage, dice che è nato per dati che i cookie gestiscono male, "perché vengono trasmessi a ogni richiesta".

Proprietà	Cookie	Local storage
Definito in	RFC 6265, in fase di sostituzione con draft-ietf-httpbis-rfc6265bis	Standard HTML del WHATWG, sezione 12
Dimensione	Almeno 4096 byte per cookie (minimo della RFC 6265)	5 MiB per origine (MDN)
Scadenza	Expires o Max-Age, oppure fine della sessione	Nessuna, resta finché non viene eliminato
Inviato al server	Sì, nell'intestazione Cookie delle richieste corrispondenti	Mai, a meno che uno script lo invii
Leggibile da JavaScript	Sì tramite document.cookie, a meno che sia HttpOnly	Sempre, da qualsiasi script nell'origine
Attributi di sicurezza	HttpOnly, Secure, SameSite, Domain, Path	Nessuno
Ambito	Dominio e percorso, nessun isolamento per porta	Origine: schema, host e porta
Safari ITP	Cookie impostati con document.cookie limitati a 7 giorni	Eliminato dopo 7 giorni di uso di Safari senza interazione
Articolo 5(3) ePrivacy	Rientra	Rientra

Quanti dati possono contenere un cookie e il local storage?

Un cookie contiene circa 4 KB e il local storage circa 5 MiB per origine, una differenza di più di mille volte. Il numero dei cookie viene dalla RFC 6265, sezione 6.1, che fissa un minimo e non un massimo. Gli user agent "DOVREBBERO fornire" almeno "4096 byte per cookie (misurati come somma della lunghezza di nome, valore e attributi del cookie)", almeno "50 cookie per dominio" e almeno "3000 cookie in totale".

La bozza che la sostituisce cambia la natura di quel numero. In draft-ietf-httpbis-rfc6265bis-22, datata dicembre 2025 e indicata dall'IETF datatracker come Internet-Draft attiva in cammino verso lo stato di Proposed Standard, il browser deve "ignorare del tutto il cookie" se "la somma delle lunghezze di cookie-name e cookie-value supera 4096 ottetti", e il valore di ogni attributo è limitato a 1024 ottetti. Il minimo da supportare è diventato un massimo rigido. La storia di quella cifra è nell'articolo sul limite di dimensione dei cookie.

Lo standard HTML non fissa alcuna dimensione per il local storage. Dice solo che setItem() "Lancia un QuotaExceededError se non è stato possibile impostare il nuovo valore." Il numero con cui si lavora viene dalla pagina di MDN sulle quote di archiviazione: "I browser possono memorizzare fino a 5 MiB di local storage e 5 MiB di session storage per origine", con il Web Storage "limitato a un massimo di 10 MiB di dati su tutti i browser."

Da minimo a massimo

RFC 6265, la regola attuale

• Gli user agent "DOVREBBERO fornire" almeno 4096 byte per cookie
• Almeno 50 cookie per dominio
• Almeno 3000 cookie in totale
• Un minimo che il browser dovrebbe raggiungere, non un limite da rispettare

rfc6265bis-22, la bozza di dicembre 2025

• Il browser deve "ignorare del tutto il cookie" oltre i 4096 ottetti
• Valore di ogni attributo limitato a 1024 ottetti
• Lo stesso numero trasformato in massimo rigido

Quando scadono i cookie e il local storage?

Un cookie scade quando passa la data di Expires o termina Max-Age, oppure alla fine della sessione se non ha nessuno dei due, mentre il local storage non ha alcuna scadenza. MDN lo dice senza giri di parole: "i dati di localStorage non hanno data di scadenza", tranne nella navigazione privata, dove vengono "cancellati alla chiusura dell'ultima scheda 'privata'." sessionStorage è il fratello a vita breve e viene cancellato quando finisce la sessione della pagina.

I cookie stanno per avere un limite massimo. La sezione 5.5 della bozza rfc6265bis dice che un browser "DEVE limitare l'età massima del cookie" e che "il limite NON DOVREBBE essere superiore a 400 giorni (34.560.000 secondi) nel futuro."

Lo standard HTML lascia al browser l'eliminazione del local storage: "Gli user agent possono, eventualmente in un modo configurato dall'utente, eliminare automaticamente i dati memorizzati dopo un certo periodo di tempo." Apple ha sfruttato questa possibilità.

Quale dei due viene inviato a ogni richiesta HTTP?

I cookie vengono inviati a ogni richiesta HTTP corrispondente, mentre il local storage non viene mai inviato dal browser in autonomia. La RFC 6265 avverte i server di tenere i cookie piccoli "per ridurre al minimo la banda di rete, dato che l'intestazione Cookie è inclusa in ogni richiesta." La bozza aggiunge che "molte implementazioni diffuse hanno limiti predefiniti di 8192 ottetti" per un'intestazione e che superarli "potrebbe far fallire le richieste al server."

"Corrispondente" significa che la richiesta rispetta le regole di dominio, percorso, Secure e SameSite del cookie. Un valore nel local storage arriva a un server solo se il tuo script lo legge e lo inserisce in una richiesta, in un URL o in un corpo.

JavaScript può leggere i cookie e il local storage?

JavaScript può leggere ogni valore del local storage nella sua origine e ogni cookie tranne quelli contrassegnati come HttpOnly. L'interfaccia Storage dello standard HTML espone esattamente sei membri: length, key(), getItem(), setItem(), removeItem() e clear(). Nessuno di loro nasconde un valore agli script, quindi qualsiasi script della pagina, compreso un tag di terze parti o del codice iniettato, può chiamare localStorage.getItem().

I cookie hanno una via d'uscita. La RFC 6265, sezione 4.1.2.6, dice che HttpOnly "istruisce lo user agent a omettere il cookie quando fornisce accesso ai cookie tramite API 'non HTTP' (come un'API del browser che espone i cookie agli script)." L'annuncio di WebKit su ITP 2.1 del 21 febbraio 2019 dà la regola pratica: "I cookie di autenticazione dovrebbero essere Secure e HttpOnly per proteggerli da attacchi man-in-the-middle, attacchi cross-site scripting e attacchi di esecuzione speculativa." Il local storage non ha modo di rispettare questa regola, ed è per questo che un token di sessione va in un cookie HttpOnly e non in localStorage.

Cosa fanno gli attributi HttpOnly, Secure e SameSite?

I tre attributi limitano chi può leggere un cookie e quando il browser lo invia, e il local storage non ha un equivalente per nessuno dei tre.

• HttpOnly nasconde il cookie agli script, come citato sopra. Un cookie impostato tramite document.cookie non può averlo, quindi solo l'intestazione Set-Cookie di un server ne crea uno.
• Secure, secondo la RFC 6265 sezione 4.1.2.5, significa che "lo user agent includerà il cookie in una richiesta HTTP solo se la richiesta viene trasmessa su un canale sicuro (tipicamente HTTP su Transport Layer Security (TLS))."
• SameSite è definito nella bozza rfc6265bis, sezione 4.1.2.7. Con Strict, "il cookie sarà inviato solo insieme a richieste 'same-site'." Con Lax, viene inviato anche "con navigazioni 'cross-site' di primo livello." Con None, viaggia con "richieste same-site e cross-site." MDN aggiunge che SameSite=None richiede Secure e che "alcuni browser usano Lax come valore predefinito se SameSite non è specificato."

Anche l'ambito è diverso. Il local storage appartiene a una sola origine, cioè schema, host e porta insieme. I cookie sono più larghi. La RFC 6265 sezione 8.5 afferma che "i cookie non offrono isolamento per porta", e l'attributo Domain condivide un cookie tra sottodomini.

Come gestisce Safari il local storage e i cookie?

Safari elimina il local storage e ogni altra forma di archiviazione scrivibile da script dopo sette giorni di utilizzo di Safari senza interazione dell'utente con il sito. WebKit ha annunciato la regola il 24 marzo 2020 in "Full Third-Party Cookie Blocking and More", osservando che "API come LocalStorage non hanno alcuna funzione di scadenza". L'ITP elimina "tutta l'archiviazione scrivibile da script di un sito web dopo sette giorni di utilizzo di Safari senza interazione dell'utente con il sito". L'elenco comprende IndexedDB, LocalStorage, media keys, SessionStorage, oltre a registrazioni e cache dei service worker.

Il conteggio riguarda i giorni di utilizzo di Safari, non i giorni di calendario, e le web app aggiunte alla schermata Home hanno un contatore a parte. I cookie impostati con document.cookie erano già limitati a sette giorni dall'ITP 2.1 di febbraio 2019. I cookie impostati dal server sfuggono a entrambe le regole: la sezione sull'eviction di MDN afferma che "i cookie impostati dal server sono esenti da questa eliminazione". Le condizioni che fanno scattare il limite e la variante da 24 ore sono spiegate in come funziona il limite di 7 giorni dei cookie di Safari.

La legge UE tratta il local storage in modo diverso dai cookie?

No. La legge UE tratta il local storage esattamente come un cookie, perché l'articolo 5(3) della direttiva ePrivacy regola l'atto di archiviare e leggere, non la tecnologia. Il testo consolidato della direttiva 2002/58/CE recita:

Gli Stati membri provvedono affinché l'archiviazione di informazioni oppure l'accesso a informazioni già archiviate nell'apparecchiatura terminale di un abbonato o di un utente sia consentito unicamente a condizione che l'abbonato o l'utente interessato abbia espresso il proprio consenso, dopo essere stato informato in modo chiaro e completo, a norma della direttiva 95/46/CE, tra l'altro sulle finalità del trattamento. Ciò non impedisce l'eventuale archiviazione tecnica o l'accesso al solo fine di effettuare la trasmissione di una comunicazione su una rete di comunicazione elettronica, o se strettamente necessario al fornitore di un servizio della società dell'informazione esplicitamente richiesto dall'abbonato o dall'utente per erogare tale servizio.

La parola "cookie" non compare. Le Linee guida 2/2023 dell'EDPB sull'ambito tecnico dell'articolo 5(3), versione 2.0 adottata il 7 ottobre 2024, affermano al paragrafo 37 che la direttiva non pone alcun "limite massimo o minimo alla durata per cui un'informazione deve persistere su un supporto di archiviazione per essere considerata archiviata, né alcun limite massimo o minimo alla quantità di informazioni da archiviare". Il paragrafo 44 cita insieme "cookie, local storage, WebSQL". Traccia inoltre l'unica linea che nella pratica li separa: un browser che usa quelle informazioni solo all'interno del dispositivo non compie un "accesso" "finché l'informazione non lascia il dispositivo, ma quando questa informazione o una sua qualsiasi derivazione viene consultata, si applica l'articolo 5(3) della direttiva ePrivacy".

Quindi uno script che scrive un identificativo in localStorage e poi lo invia a un server archivia informazioni e vi accede, e richiede il consenso a meno che non si applichi un'esenzione. Spostare un ID di tracciamento da un cookie al local storage cambia il comportamento del browser, ma lascia identica la risposta giuridica. Per questo uno strumento descritto come tracciamento senza cookie deve comunque dichiarare che cosa archivia sul dispositivo. Le esenzioni funzionano allo stesso modo per entrambi. Dipendono dallo scopo, non dalla tecnologia: un uso "strettamente necessario" in un cookie lo è con lo stesso ragionamento nel local storage, e un uso che richiede il consenso in un cookie lo richiede anche nel local storage.

Domande frequenti

Il local storage è più sicuro dei cookie?

No. Qualsiasi script dell'origine può leggere il local storage, che non ha un equivalente di HttpOnly. Per questo WebKit consiglia di tenere l'autenticazione in cookie Secure e HttpOnly.

Il local storage richiede un banner dei cookie?

Richiede lo stesso consenso di un cookie quando non è strettamente necessario. L'articolo 5(3) della direttiva ePrivacy copre "l'archiviazione di informazioni" sul dispositivo, qualunque sia l'API di archiviazione.

Qual è il limite di dimensione del local storage?

MDN indica 5 MiB per origine, più 5 MiB di session storage. Lo standard HTML non fissa alcuna cifra; setItem() lancia QuotaExceededError quando una scrittura fallisce.

Il local storage scade?

No. Il local storage non ha un attributo di scadenza, ma i browser lo eliminano comunque: l'ITP di Safari dopo sette giorni di utilizzo di Safari senza interazione, la navigazione privata quando si chiude l'ultima scheda privata.

Il server può leggere il local storage?

No. Il browser non invia mai il local storage in una richiesta. Il server vede un valore solo se uno script lo legge e lo invia, mentre i cookie finiscono automaticamente nell'header Cookie.

sessionStorage è diverso da localStorage?

Sì. sessionStorage appartiene a una sola scheda e viene cancellato quando termina la sessione di quella pagina, mentre localStorage è condiviso tra le schede dell'origine e persiste. Entrambi rientrano nella regola dei sette giorni di Safari.

Un token di sessione può stare al sicuro nel local storage?

Un token di sessione va in un cookie con gli attributi Secure e HttpOnly, non nel local storage, perché qualsiasi script dell'origine può chiamare localStorage.getItem() e leggerlo. L'annuncio dell'ITP 2.1 di WebKit fa la stessa osservazione per i cookie di autenticazione. Il local storage non ha alcun attributo che nasconda un valore agli script.

Quanto può durare un cookie secondo l'ultima bozza sui cookie?

La bozza rfc6265bis limita per la prima volta la durata dei cookie: la sezione 5.5 richiede che il browser limiti l'età massima di un cookie e raccomanda che il limite non superi i 400 giorni. Il local storage non ha una regola simile nello standard HTML, che permette al browser soltanto di eliminare i dati archiviati a propria discrezione.

I cookie e il local storage condividono i dati tra sottodomini?

Un cookie può essere condiviso tra sottodomini tramite l'attributo Domain, e la RFC 6265 osserva che i cookie non offrono isolamento per porta. Il local storage non ha questa opzione: appartiene a una sola origine, definita da schema, host e porta insieme, quindi uno script su un sottodominio non può leggere il local storage del dominio padre.

Che cosa succede a un cookie che supera il limite di 4096 byte della bozza?

Secondo draft-ietf-httpbis-rfc6265bis-22, il browser deve ignorare del tutto il cookie quando la lunghezza combinata di nome e valore supera i 4096 ottetti. Il minimo della vecchia RFC 6265, una soglia che gli user agent DOVREBBERO garantire, diventa così un tetto rigido. Lo standard HTML non fissa un limite paragonabile per il local storage; setItem() lancia QuotaExceededError solo quando il nuovo valore non può essere impostato.