Web Storage (localStorage/sessionStorage)

Web Storage è l'API HTML5 per memorizzare dati key-value nel browser. Offre due meccanismi: localStorage (persistente) e sessionStorage (per sessione). Sostituisce in gran parte i cookie per dati non sensibili, con quote molto maggiori e API più semplice. Vediamo differenze, limitazioni, casi d'uso e best practice per usarli senza incorrere in errori comuni.

localStorage vs sessionStorage

localStorage persiste anche dopo la chiusura del browser e ricarica delle pagine, condiviso tra tutte le tab dello stesso origin. sessionStorage esiste solo per la durata della sessione del browser, isolato per tab. Entrambi seguono Same-Origin Policy: dati di esempio.it non sono accessibili da altro.it. Quota tipica: 5-10 MB per origin per ciascun tipo di storage, ampia per la maggior parte degli usi.

API e tipi di dato

Metodi principali: setItem(key, value), getItem(key), removeItem(key), clear(), key(index). I valori sono sempre stringhe: per oggetti serializza con JSON.stringify e deserializza con JSON.parse. Length restituisce il numero di item. L'evento storage notifica modifiche da altre tab dello stesso origin, utile per sincronizzare stato tra finestre, come logout o aggiornamento del carrello in tempo reale.

Quando usare IndexedDB invece

Web Storage è semplice ma limitato: solo stringhe, quote ~5-10MB, sincrono (blocca il main thread). Per dati strutturati grandi (oltre 1MB) o quando serve query e indici, IndexedDB è la scelta giusta: storage transazionale, asincrono, fino a centinaia di MB. Library come Dexie.js o idb-keyval semplificano l'API verbosa di IndexedDB. Pattern tipico: localStorage per preferenze utente e flag, IndexedDB per cache offline di dati applicativi, dataset, immagini. Combinati offrono persistenza client robusta per applicazioni offline-first.

Cookie vs Web Storage

Cookie sono inviati con ogni richiesta HTTP, ideali per autenticazione (HttpOnly + Secure + SameSite). Web Storage resta solo client, mai inviato automaticamente al server, ottimo per dati che il backend non deve vedere ad ogni richiesta. Cookie quota: ~4KB per cookie, ~50 per dominio. localStorage quota: MB. Per token di autenticazione, HttpOnly cookie è più sicuro perché immune a XSS. Per stato UI, preferenze tema, draft di form e simili, localStorage è la scelta naturale e performante.

Storage events e sincronizzazione

L'evento storage permette di sincronizzare lo stato tra tab dello stesso origin. Quando una tab modifica localStorage, altre tab ricevono l'evento storage con dettagli del cambiamento. Use case: logout in una tab fa logout in tutte, carrello sincronizzato tra finestre, tema dark/light coordinato. Sintassi: window.addEventListener('storage', e => { if (e.key === 'authToken' && !e.newValue) logout() }). Importante: l'evento non si attiva nella tab che ha eseguito la modifica, solo nelle altre. Pattern semplice per UX coerente in app multi-tab senza WebSocket.

Sicurezza e best practice

Web Storage è vulnerabile a XSS: qualsiasi script eseguito nella pagina può leggere localStorage. Mai memorizzare token di autenticazione, dati personali sensibili, password. Per token usa HttpOnly cookie + CSRF protection. Per dati personali sensibili usa server-side session storage con sessionId opaco nel cookie. Web Storage va usato per: preferenze UI, draft di form, cache di dati non sensibili, flag di stato. Sanitizza sempre i dati prima di leggerli (potrebbero essere stati corrotti da malware o estensioni browser). Backup importante: implementa fallback graceful se localStorage non è disponibile o pieno.

Storage API moderne

Oltre a localStorage, le API di storage del browser moderno includono: IndexedDB per dati strutturati grandi e query, Cache API per cache di risorse network (usata da Service Workers per offline), CookieStore API (alternativa moderna a document.cookie), Storage Access API per cross-site cookie con consenso. navigator.storage.estimate() restituisce uso e quota disponibile. navigator.storage.persist() richiede storage persistente che non viene evicted automaticamente. Per applicazioni offline-first, combina Service Worker + Cache API per asset + IndexedDB per dati. Pattern moderno completo per app installabili PWA che funzionano senza connessione e sincronizzano quando online.

Procedura passo-passo

1. Salva una stringa: localStorage.setItem('username', 'mario').
2. Leggi: const user = localStorage.getItem('username').
3. Per oggetti: localStorage.setItem('user', JSON.stringify(obj)).
4. Recupera oggetti: const obj = JSON.parse(localStorage.getItem('user') || '{}').
5. Rimuovi singolo item: localStorage.removeItem('username').
6. Svuota tutto: localStorage.clear().
7. Sincronizza tra tab: window.addEventListener('storage', handler).

Errori comuni e come risolverli

• Dati sensibili in localStorage: visibili a qualsiasi script della pagina (XSS); non salvare token JWT.
• Mancata gestione quota: setItem può lanciare QuotaExceededError; try/catch e cleanup.
• Non serializzare oggetti: localStorage memorizza stringhe; usa JSON.stringify/parse.
• localStorage in incognito: alcuni browser bloccano scrittura in incognito; gestisci con try/catch.
• SSR error: localStorage non esiste su Node.js; verifica typeof window prima dell'uso.

Domande frequenti

D: Posso memorizzare oggetti complessi?
R: Solo serializzati come stringa JSON. Per dati complessi/grandi usa IndexedDB.

D: localStorage scade?
R: No, persiste finché l'utente non lo cancella manualmente o tramite codice.

D: Quanto è grande la quota?
R: Tipicamente 5-10 MB per origin. Verifica con navigator.storage.estimate per dati precisi.

D: localStorage e sessionStorage sono sicuri?
R: Vulnerabili a XSS. Non memorizzare token o dati sensibili; usa HttpOnly cookie per sicurezza maggiore.

Hai bisogno di aiuto?

Se vuoi sviluppo web con il team di G Tech Group, scrivici tramite il modulo di contatto.