Risposta Rapida: SessionStorage e localStorage sono entrambe API di Web Storage basate su browser che consentono ai siti web di memorizzare dati sul dispositivo di un utente, ma differiscono in modo critico in termini di persistenza e ambito. localStorage conserva i dati indefinitamente tra sessioni e schede, mentre sessionStorage cancella i dati quando la scheda del browser si chiude. Da un punto di vista della privacy, localStorage comporta un rischio sostanzialmente più elevato poiché i dati rimangono senza scadenza, rendendolo un obiettivo più attraente per il tracciamento, il fingerprinting e il controllo normativo sotto quadri come il GDPR.
Punti Chiave
- localStorage persiste indefinitamente fino a quando non viene esplicitamente cancellato; sessionStorage viene eliminato quando la scheda o la finestra si chiude.
- Entrambi i tipi di archiviazione sono vulnerabili ad attacchi di cross-site scripting (XSS) e non offrono crittografia integrata.
- Né i dati di localStorage né quelli di sessionStorage vengono trasmessi automaticamente al server, a differenza dei cookie, ma entrambi sono completamente leggibili da qualsiasi JavaScript in esecuzione sulla stessa origine.
- Gli script di terze parti caricati su una pagina possono accedere ai dati di localStorage se vengono eseguiti all'interno dello stesso contesto di origine.
- Ai sensi del GDPR, memorizzare dati non essenziali in localStorage senza il consenso dell'utente è una violazione della conformità, così come l'inserimento di cookie di tracciamento.
- Dati sensibili come token di autenticazione, password e informazioni identificabili personalmente (PII) non dovrebbero mai essere memorizzati in nessuno dei due meccanismi senza ulteriori livelli di sicurezza.
- La navigazione privata/incognito limita la persistenza di localStorage ma non elimina i rischi di sessionStorage all'interno di una sessione.
- Gli sviluppatori dovrebbero preferire sessionStorage per stati temporanei, sessioni lato server o cookie HttpOnly per l'autenticazione, e una Piattaforma di Gestione del Consenso come Biscotti CMP per gestire il consenso all'archiviazione.
Qual è la Differenza tra SessionStorage e LocalStorage?
SessionStorage e localStorage fanno entrambi parte dell'API di Web Storage HTML5, ma servono a scopi distinti definiti dalla loro persistenza e comportamento di ambito della scheda.
localStorage memorizza coppie chiave-valore senza data di scadenza. I dati sopravvivono ai riavvii del browser, ai riavvii del sistema e a periodi indefiniti di inattività fino a quando l'utente o l'applicazione non li rimuovono esplicitamente. È condiviso tra tutte le schede e finestre che operano sotto la stessa origine (protocollo + dominio + porta). [1][5]
sessionStorage memorizza i dati solo per la durata della sessione della pagina. Quando l'utente chiude la scheda o la finestra, i dati scompaiono. Criticamente, ogni scheda mantiene il proprio sessionStorage isolato, aprire la stessa URL in una seconda scheda non condivide i dati di sessionStorage della prima scheda. [1]
| Caratteristica | localStorage | sessionStorage |
|---|---|---|
| Persistenza | Indefinita | Solo durata scheda/finestra |
| Condiviso tra schede | Sì (stessa origine) | No (isolamento per scheda) |
| Sopravvive al ricaricamento della pagina | Sì | Sì |
| Sopravvive alla chiusura della scheda | Sì | No |
| Capacità di archiviazione | ~5-10 MB per origine | ~5-10 MB per origine |
| Trasmissione al server | No | No |
| Protezione HttpOnly | Non disponibile | Non disponibile |
Entrambe le API aderiscono alla politica di stessa origine, quindi una pagina su https://example.com non può leggere l'archiviazione impostata da https://otherdomain.com. [4]
LocalStorage Ha Rischi per la Privacy Rispetto a SessionStorage?
Sì, localStorage comporta rischi per la privacy significativamente più elevati rispetto a sessionStorage, principalmente a causa della sua persistenza indefinita e dell'accessibilità tra schede.
I dati scritti in localStorage possono accumularsi nel tempo senza che l'utente ne sia a conoscenza. Gli inserzionisti e i fornitori di analisi hanno storicamente utilizzato localStorage come un "super-cookie", un identificatore di tracciamento che sopravvive alla cancellazione dei cookie perché la maggior parte degli utenti non pensa di cancellare manualmente l'archiviazione del browser. sessionStorage, al contrario, si autodistrugge alla chiusura della scheda, rendendolo un vettore di tracciamento molto meno utile.
Fattori di rischio per la privacy unici per localStorage:
- Identificatori di tracciamento persistenti: Un ID unico memorizzato in localStorage può tracciare un utente attraverso più visite senza alcun cookie lato server.
- Perdita di dati tra schede: Qualsiasi script in esecuzione in qualsiasi scheda della stessa origine può leggere tutti i dati di localStorage.
- Broadcasting di eventi di archiviazione: Le modifiche a localStorage attivano un evento
storagein altre schede aperte della stessa origine, abilitando la sincronizzazione dei dati tra schede che gli utenti non possono osservare. [5] - Nessuna scadenza automatica: A differenza dei cookie, che supportano gli attributi
Max-AgeeExpires, localStorage non ha meccanismi TTL.
I Siti Web Possono Tracciare gli Utenti Utilizzando localStorage e sessionStorage?
I siti web possono e usano localStorage per il tracciamento persistente. sessionStorage è meno utile per il tracciamento ma presenta comunque rischi di sorveglianza all'interno della sessione.
Una singola riga di JavaScript, localStorage.setItem('uid', 'abc123'), crea un identificatore persistente che sopravvive alla cancellazione dei cookie. Questa tecnica, a volte chiamata "evercookie" o respawning basato su archiviazione, è stata documentata nella ricerca sulla privacy ed è il motivo per cui i regolatori trattano sempre più localStorage sotto le stesse regole di consenso dei cookie.
sessionStorage può tracciare il comportamento all'interno di una singola sessione (flusso di pagina, input di moduli, schemi di navigazione), ma quei dati scompaiono quando la scheda si chiude, limitando la sua utilità per il profilo a lungo termine.
Quanto Tempo Rimangono i Dati in SessionStorage Rispetto a LocalStorage?
I dati di localStorage rimangono fino a quando non vengono esplicitamente eliminati, sia dall'utente che cancella l'archiviazione del browser, sia dal sito web che chiama localStorage.removeItem() o localStorage.clear(), sia dal browser che applica quote di archiviazione. [2]
I dati di sessionStorage vengono eliminati automaticamente quando la scheda o la finestra che li ha creati viene chiusa. Sopravvivono ai ricaricamenti della pagina all'interno della stessa scheda ma non si trasferiscono a nuove schede, anche se l'utente duplica la scheda in alcuni browser. [1]
Implicazione pratica: Se uno sviluppatore memorizza un token di sessione in localStorage invece di sessionStorage, quel token rimane sul dispositivo dopo che l'utente ha effettuato il logout, a meno che l'applicazione non lo rimuova esplicitamente. Questo è un errore comune e significativo.
SessionStorage È Più Privato di LocalStorage?
Per la maggior parte dei casi d'uso della privacy, sì, sessionStorage è la scelta che rispetta di più la privacy. La sua eliminazione automatica alla chiusura della scheda significa che i dati non rimangono, riducendo l'esposizione da condivisione di dispositivi, dispositivi rubati o analisi forense.
Tuttavia, sessionStorage non è intrinsecamente "privato". All'interno di una sessione attiva, è altrettanto vulnerabile agli attacchi XSS quanto localStorage. Qualsiasi script iniettato può chiamare sessionStorage.getItem() ed esfiltrare dati in tempo reale. [3]
Scegli sessionStorage se: i dati sono necessari solo per l'interazione utente corrente (ad es., stato di un modulo multi-passaggio, token di navigazione una tantum).
Scegli localStorage se: i dati devono realmente persistere tra le sessioni (ad es., preferenze UI dell'utente, impostazioni non sensibili), e assicurati che non contengano nulla di identificabile personalmente.
Quali Dati Personali Non Dovrebbero Mai Essere Memorizzati in localStorage?
Le seguenti categorie di dati non dovrebbero mai essere memorizzate in localStorage (e dovrebbero essere gestite con estrema cautela anche in sessionStorage): [3]
- Token di autenticazione (JWT, token OAuth, ID di sessione)
- Password o hash delle password
- Informazioni su carte di credito o pagamenti
- Numeri di identificazione rilasciati dal governo o numeri di previdenza sociale
- Nomi completi combinati con indirizzi email o numeri di telefono
- Cartelle cliniche o dati sanitari
- Qualsiasi dato classificato come "categoria speciale" ai sensi del GDPR (dati biometrici, dati sanitari, opinioni politiche)
I dati memorizzati sia in localStorage che in sessionStorage non sono crittografati per impostazione predefinita. Chiunque abbia accesso fisico al dispositivo, o qualsiasi script in grado di eseguire sulla pagina, può leggerli in testo chiaro. [3]
Gli Script di Terze Parti Possono Accedere ai Dati di localStorage?
Gli script di terze parti possono accedere ai dati di localStorage se vengono caricati ed eseguiti all'interno della stessa origine della pagina host. Questo è un rischio critico e frequentemente sottovalutato.
Quando un sito web incorpora uno script di analisi o pubblicità di terze parti tramite un tag <script>, quello script viene eseguito nel contesto di origine della pagina host. Può leggere e scrivere liberamente nell'archiviazione locale del sito. La politica di stessa origine non protegge contro gli script che sono intenzionalmente o involontariamente inclusi nella pagina. [4]
Cosa significa questo in pratica: Se un sito memorizza un identificatore utente in localStorage e carica anche uno script pubblicitario di terze parti, quello script pubblicitario può leggere l'identificatore e associarlo ai dati comportamentali cross-site, senza la conoscenza o il consenso dell'utente.
Questo è uno dei motivi per cui le Piattaforme di Gestione del Consenso sono importanti. Biscotti CMP consente ai siti web di gestire e documentare il consenso degli utenti per le operazioni di archiviazione, incluso il tracciamento basato su localStorage, aiutando i siti a soddisfare i loro obblighi ai sensi del GDPR e di quadri simili.
Quali Sono le Implicazioni del GDPR nell'Utilizzo di localStorage?
Ai sensi del GDPR, qualsiasi archiviazione di dati personali o identificatori di tracciamento, indipendentemente dal meccanismo tecnico, richiede una base giuridica. Per il tracciamento non essenziale tramite localStorage, tale base è quasi sempre il consenso esplicito dell'utente. [2]
Il Comitato Europeo per la Protezione dei Dati ha confermato che l'uso di localStorage per analisi, pubblicità o profilazione degli utenti rientra negli stessi requisiti di consenso dei cookie. I siti web che inseriscono identificatori di tracciamento in localStorage senza consenso preventivo affrontano la stessa esposizione all'applicazione di quelli che utilizzano cookie non consenzienti.
Checklist di conformità per localStorage ai sensi del GDPR:
- Audit di tutte le chiavi di localStorage scritte da script di prima e terza parte.
- Classificare ogni chiave: è strettamente necessaria per il servizio, o è utilizzata per analisi/pubblicità?
- Per l'archiviazione non essenziale, limitare l'operazione di scrittura dietro il consenso documentato dell'utente.
- Fornire agli utenti un meccanismo chiaro per ritirare il consenso e attivare l'eliminazione dell'archiviazione.
- Documentare l'interesse legittimo del titolare del trattamento o il record di consenso.
Una Piattaforma di Gestione del Consenso configurata correttamente come Biscotti CMP può automatizzare gran parte di questo ciclo di vita del consenso.
Può essere Accessibile localStorage tra Siti Web Diversi?
No. localStorage è strettamente limitato all'origine (combinazione di protocollo + dominio + porta) che lo ha creato. Uno script su https://siteA.com non può leggere i dati di localStorage impostati da https://siteB.com. [4]
Tuttavia, questa protezione ha dei limiti. Se un singolo fornitore di pubblicità o analisi carica i propri script sia su siteA.com che su siteB.com, ogni istanza scrive in modo indipendente nell'archiviazione locale di quel sito rispettivo. Il fornitore quindi correla i dati lato server, ottenendo effettivamente un tracciamento cross-site senza violare la politica di stessa origine.
Come Influiscono la Modalità Incognito e la Navigazione Privata su localStorage?
La navigazione privata/incognito crea una partizione di archiviazione temporanea che viene eliminata quando la finestra privata si chiude. localStorage scritto durante una sessione in incognito non persiste nel profilo principale del browser e non è accessibile alle finestre di navigazione normali.
sessionStorage si comporta allo stesso modo in incognito come nella navigazione normale: viene eliminato quando la scheda si chiude.
Importanti avvertenze:
- All'interno di una sessione incognito attiva, localStorage è ancora leggibile da tutti gli script in esecuzione nel contesto di stessa origine di quella sessione.
- La modalità incognito non previene l'esfiltrazione di dati in tempo reale basata su XSS.
- Alcuni browser sincronizzano localStorage tra dispositivi se l'utente è connesso alla sincronizzazione del browser, un comportamento che può spostare i dati "locali" nell'infrastruttura cloud.
Come Posso Cancellare SessionStorage e localStorage per la Privacy?
Cancellare l'archiviazione del browser è semplice ma richiede un'azione deliberata poiché i browser non lo fanno automaticamente per localStorage.
Cancellazione a livello di browser:
- Chrome: Impostazioni > Privacy e Sicurezza > Cancella dati di navigazione > Immagini e file memorizzati + Dati del sito
- Firefox: Impostazioni > Privacy e Sicurezza > Cookie e Dati del sito > Cancella Dati
- Safari: Impostazioni > Privacy > Gestisci Dati dei Siti
Cancellazione programmatica (per sviluppatori):
localStorage.clear()rimuove tutte le chiavi per l'origine.sessionStorage.clear()rimuove tutte le chiavi per la sessione della scheda corrente.localStorage.removeItem('keyName')rimuove una chiave specifica.
Per gli utenti finali preoccupati per il tracciamento: cancellare "dati del sito" o "cookie e archiviazione" nelle impostazioni del browser rimuove sia i contenuti di localStorage che di sessionStorage per tutti i siti. Le estensioni del browser progettate per la privacy possono automatizzare questo su base per sito o per sessione.
Quali Sono gli Errori Comuni di Privacy che Gli Sviluppatori Fanno con il Web Storage?
Gli errori più significativi condividono una radice comune: trattare l'archiviazione lato client come se fosse un database sicuro lato server.
- Memorizzare JWT in localStorage: I token di autenticazione memorizzati in localStorage sono accessibili a qualsiasi script sulla pagina. Una singola vulnerabilità XSS espone il token di ogni utente. Utilizzare cookie HttpOnly per i token di autenticazione invece.
- Nessuna logica di scadenza: localStorage non ha TTL. Gli sviluppatori che memorizzano dati senza costruire logica di scadenza lasciano dati sensibili obsoleti sui dispositivi indefinitamente.
- Assumere che la stessa origine significhi sicuro: La politica di stessa origine blocca i siti esterni, non gli script dannosi caricati da dentro lo stesso sito (XSS, librerie di terze parti compromesse).
- Ignorare l'accesso degli script di terze parti: Incorporare script di analisi o pubblicità senza verificare cosa leggono da localStorage.
- Nessun gate di consenso per l'archiviazione di tracciamento: Scrivere identificatori di analisi in localStorage prima di ottenere il consenso dell'utente, una violazione diretta del GDPR. [2]
- Memorizzare PII ridondante: Memorizzare risposte API che includono profili utente completi in localStorage "per prestazioni" senza considerare la superficie di esposizione.
IndexedDB È Più Privato di localStorage?
IndexedDB non è intrinsecamente più privato di localStorage. Entrambi sono governati dalla politica di stessa origine, entrambi sono accessibili a JavaScript in esecuzione sulla pagina e entrambi sono vulnerabili ad attacchi XSS.
IndexedDB offre una maggiore capacità di archiviazione e supporta dati strutturati e blob binari, rendendolo adatto per applicazioni offline complesse. Ma da un punto di vista della privacy e della sicurezza, i rischi sono comparabili. I dati memorizzati in IndexedDB sono anch'essi non crittografati per impostazione predefinita e persistono indefinitamente a meno che non vengano eliminati esplicitamente.
La scelta tra IndexedDB e localStorage dovrebbe essere guidata dalla complessità dei dati e dai requisiti di volume, non da assunzioni sulla privacy. Nessuno dei due è appropriato per dati personali sensibili senza crittografia a livello di applicazione e rigorosi controlli di accesso.
Conclusione
Il dibattito su SessionStorage vs. LocalStorage: Implicazioni sulla Privacy delle API di Web Storage non è semplicemente una nota tecnica, ha conseguenze dirette per la privacy degli utenti, la conformità normativa e la sicurezza delle applicazioni. La persistenza indefinita di localStorage e l'accessibilità tra schede lo rendono un meccanismo di archiviazione ad alto rischio quando viene utilizzato in modo improprio, mentre l'eliminazione automatica di sessionStorage alla chiusura della scheda lo rende la scelta più difendibile per stati temporanei.
Passi successivi praticabili per sviluppatori e proprietari di siti web nel 2026:
- Audit di tutto l'uso di localStorage e sessionStorage attraverso script di prima e terza parte utilizzando gli strumenti di sviluppo del browser (scheda Applicazione).
- Rimuovere immediatamente qualsiasi token di autenticazione, PII o identificatori sensibili dall'archiviazione lato client.
- Sostituire l'archiviazione dei token di autenticazione basata su localStorage con cookie HttpOnly, Secure gestiti lato server.
- Implementare un flusso di gestione del consenso, utilizzando una piattaforma come Biscotti CMP, per limitare le scritture non essenziali di localStorage dietro il consenso documentato dell'utente.
- Costruire logica di scadenza in qualsiasi dato di localStorage che deve persistere e applicare la pulizia al logout.
- Condurre un audit degli script di terze parti per comprendere quale codice esterno può leggere dall'archiviazione della tua origine.
- Formare i team di sviluppo sulla prevenzione degli attacchi XSS come vettore di attacco principale contro entrambi i tipi di archiviazione.
Le API di archiviazione web sono strumenti potenti. Utilizzate senza disciplina sulla privacy, diventano vettori di responsabilità. Utilizzate con scoping deliberato, gestione del consenso e igiene della sicurezza, servono al loro scopo previsto senza compromettere gli utenti che si fidano della tua applicazione.
FAQ
D: Qual è la principale differenza tra sessionStorage e localStorage?
localStorage persiste i dati indefinitamente tra le sessioni ed è condiviso tra tutte le schede della stessa origine. sessionStorage memorizza i dati solo per la durata della scheda corrente e viene eliminato automaticamente quando la scheda si chiude.
D: Può essere utilizzato localStorage per tracciare gli utenti senza cookie?
Sì. Un identificatore unico memorizzato in localStorage sopravvive alla cancellazione dei cookie e può essere utilizzato per tracciare gli utenti attraverso più visite allo stesso sito, funzionando come un meccanismo di tracciamento persistente.
D: È sicuro utilizzare sessionStorage per memorizzare password?
No. sessionStorage non è crittografato ed è accessibile a qualsiasi JavaScript in esecuzione sulla pagina, inclusi script dannosi iniettati. Le password non dovrebbero mai essere memorizzate in nessun meccanismo di archiviazione lato client.
D: Si applica il GDPR a localStorage?
Sì. Ai sensi del GDPR, memorizzare identificatori di tracciamento o dati personali in localStorage senza una base giuridica, tipicamente il consenso esplicito dell'utente per scopi non essenziali, è una violazione della conformità equivalente all'uso di cookie non consenzienti.
D: Gli script di terze parti possono leggere i miei dati di localStorage?
Sì, se quegli script vengono caricati ed eseguiti all'interno della stessa origine. Gli script di analisi o pubblicità di terze parti incorporati tramite tag <script> vengono eseguiti nel contesto di origine della pagina host e possono leggere tutti i dati di localStorage per quella origine.
D: Cancellare i cookie cancella anche localStorage?
Non sempre. Nella maggior parte dei browser, cancellare solo "cookie" non cancella localStorage. Gli utenti devono specificamente cancellare "dati del sito" o "cookie e altri dati del sito" per rimuovere i contenuti di localStorage.
D: La modalità incognito è sicura dal tracciamento di localStorage?
La modalità incognito impedisce ai dati di localStorage di persistere dopo la chiusura della finestra privata, ma all'interno di una sessione incognito attiva, localStorage è ancora leggibile da tutti gli script sulla pagina.
D: Cosa dovrei usare invece di localStorage per i token di autenticazione?
Utilizzare cookie HttpOnly, Secure, SameSite gestiti lato server. Questi cookie sono inaccessibili a JavaScript, eliminando il rischio di furto di token basato su XSS che comporta localStorage.
D: IndexedDB è più sicuro di localStorage?
No. IndexedDB è soggetto alle stesse vulnerabilità XSS e alla politica di stessa origine di localStorage. Offre una maggiore capacità e supporto per la struttura dei dati, ma nessuna garanzia aggiuntiva di privacy o sicurezza.
D: Quanta memoria possono contenere localStorage e sessionStorage?
La maggior parte dei browser moderni allocano circa 5-10 MB di archiviazione per origine per ciascun tipo di archiviazione, significativamente più del limite di 4 KB tipico dei cookie. [2]
Riferimenti
[1] Sessionstorage - https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage?utm_source=openai
[2] What Is Localstorage Sessionstorage - https://inspectwp.com/en/knowledge-base/what-is-localstorage-sessionstorage?utm_source=openai
[3] Html5 Web Storage Security Risks Safeguarding Localstorage And Sessionstorage - https://www.dopethemes.com/html5-web-storage-security-risks-safeguarding-localstorage-and-sessionstorage/?utm_source=openai
[4] Localstorage - https://javascript.info/localstorage?utm_source=openai
[5] Localstorage Sessionstorage - https://www.w3docs.com/learn-javascript/localstorage-sessionstorage?utm_source=openai
[6] Cookies Vs Localstorage Vs Sessionstorage What Each One Exactly Means - https://www.interserver.net/tips/kb/cookies-vs-localstorage-vs-sessionstorage-what-each-one-exactly-means/?utm_source=openai