Sicurezza: cosa non archiviare mai

localStorage e sessionStorage salvano i dati non cifrati sul disco, nel profilo dell'utente. Qualsiasi processo con accesso al file system, inclusi malware, strumenti di backup o un altro utente con accesso all'account, può leggere ogni valore memorizzato senza passare dal browser.

Tutti gli script eseguiti sull'origine condividono lo stesso Storage. Un attacco XSS riuscito, un SDK di terze parti compromesso o un'estensione del browser dannosa può chiamare localStorage.getItem ed esfiltrare ogni valore memorizzato. Non esiste alcun isolamento tra gli script.

Non inserisca token di sessione, JWT, token di aggiornamento o chiavi API in localStorage. Se un attaccante inietta una sola riga di JavaScript, il token viene sottratto immediatamente. Utilizzi cookie httpOnly, Secure e SameSite, in modo che il token non sia mai accessibile da JavaScript.

Memorizzare password in qualsiasi forma, in chiaro, con hash o cifrate, è sbagliato sul client. Applicare l'hashing sul client non aiuta quando l'attaccante può leggere l'hash e riutilizzarlo. La gestione delle password deve avvenire interamente sul server, utilizzando un hash dedicato come bcrypt.

PCI-DSS vieta di memorizzare numeri delle carte, CVV, dati della banda magnetica o date di scadenza nello storage del client. Utilizzi invece un provider di pagamenti tokenizzato (Stripe, Braintree, Adyen) che restituisca un token di breve durata associato all'origine della pagina.

I documenti di identità, le date di nascita complete, gli indirizzi di casa e i dati medici attirano l'attenzione degli enti normativi (GDPR, HIPAA) e degli aggressori. Memorizzi solo ciò che è necessario per la sessione corrente, lo richieda nuovamente quando serve e lasci che sia il server a conservare la fonte autorevole.

Un bug XSS che divulga document.cookie è grave. Lo stesso bug in una pagina che memorizza token in localStorage consegna all'aggressore tutti i valori memorizzati in una volta sola. Consideri localStorage una superficie in cui la compromissione di uno script equivale alla compromissione di tutto.

Crittografare i valori con una chiave che risiede anch'essa in JavaScript non offre alcuna protezione reale: l'aggressore che può leggere il testo cifrato può leggere anche la chiave. I segreti reali devono restare lato server e venire riemessi, mai persistiti lato client.

Le preferenze dell'interfaccia (tema, barra laterale compressa, lingua), i feature flag non sensibili, il contenuto delle bozze dei moduli e lo stato temporaneo delle procedure guidate sono tutti dati sicuri. Sono comunque visibili all'utente e la loro divulgazione non consente di assumere il controllo dell'account.

Imposti l'autenticazione tramite Set-Cookie: token=...; HttpOnly; Secure; SameSite=Strict. Il flag HttpOnly rende il cookie inaccessibile a JavaScript, neutralizzando la maggior parte dei payload XSS che rubano token, anche quando nella pagina sono presenti altri bug.

Se deve memorizzare nella cache dati che sembrano sensibili, ne limiti rigorosamente l'ambito (TTL breve, cancellazione al logout, rimozione alla chiusura della scheda tramite sessionStorage), applichi una Content Security Policy rigorosa per bloccare gli script iniettati e verifichi ogni script di terze parti eseguito nelle pagine autenticate.

Perché i token di autenticazione memorizzati in localStorage sono considerati un rischio per la sicurezza?

Web Storage è in testo semplice, leggibile dagli script e condiviso per origine. Non inserisca mai al suo interno token di autenticazione, password, dati di pagamento o informazioni personali soggette a normative. Conservi i segreti nei cookie httpOnly e riservi localStorage allo stato innocuo dell'interfaccia, che l'utente potrebbe comunque vedere.