Cosa sono localStorage e sessionStorage?

localStorage e sessionStorage sono due meccanismi forniti dall'API Web Storage, uno standard integrato in ogni browser moderno. Permettono ai siti web di memorizzare coppie chiave-valore direttamente nel browser del visitatore, senza dover coinvolgere il server a ogni caricamento di pagina. Se hai mai attivato la modalità scura su un sito web e notato il giorno successivo che la tua preferenza era ancora lì, il sito probabilmente ha memorizzato quella scelta in localStorage.

Come funziona l'API Web Storage

L'API Web Storage è deliberatamente semplice. Chiami localStorage.setItem('chiave', 'valore') per scrivere dati, localStorage.getItem('chiave') per leggere e localStorage.removeItem('chiave') per eliminare. sessionStorage utilizza esattamente gli stessi metodi. Entrambi i sistemi di archiviazione accettano solo stringhe, quindi gli oggetti vengono solitamente serializzati con JSON.stringify() prima di essere memorizzati. Non c'è linguaggio di query, indicizzazione o struttura relazionale. È un'archiviazione chiave-valore piatta progettata per letture e scritture rapide e leggere.

localStorage vs sessionStorage: differenze chiave

• Persistenza: i dati di localStorage rimangono nel browser finché l'utente o il sito non li elimina esplicitamente. Non c'è data di scadenza. I dati di sessionStorage, al contrario, vengono cancellati nel momento in cui la scheda del browser viene chiusa.
• Ambito tra le schede: localStorage è condiviso tra tutte le schede e le finestre appartenenti alla stessa origine (protocollo + dominio + porta). sessionStorage è isolato per scheda. Se apri la stessa pagina in due schede, ogni scheda ha il proprio sessionStorage.
• Limiti di archiviazione: entrambi tipicamente offrono da 5 a 10 MB per origine, a seconda del browser. Chrome e Firefox impostano per impostazione predefinita circa 5 MB per origine per archiviazione. Safari può essere più rigoroso, soprattutto in modalità privata, dove a volte limita l'archiviazione a poche centinaia di kilobyte.
• Comportamento di rete: né localStorage né sessionStorage vengono inviati al server con le richieste HTTP. Questa è la differenza fondamentale rispetto ai cookie, che vengono automaticamente allegati a ogni header di richiesta.

Cosa memorizzano tipicamente i siti WordPress

I plugin e i temi WordPress utilizzano l'archiviazione del browser per una vasta gamma di scopi. Ecco i più comuni:

• Preferenze del tema: interruttori della modalità scura, stato collassato/espanso della barra laterale, scelte di dimensione del carattere. Questi vengono quasi sempre memorizzati in localStorage, perché devono sopravvivere alla chiusura di una scheda.
• Dati del carrello: WooCommerce e plugin simili a volte memorizzano in cache i frammenti del carrello in localStorage per evitare round trip extra al server quando visualizzano il mini-carrello nell'header.
• Bozze dei moduli: i plugin per moduli di contatto possono salvare automaticamente l'input dell'utente in sessionStorage, in modo che un modulo parzialmente compilato non venga perso se l'utente si allontana accidentalmente e poi torna tramite il pulsante indietro.
• Scelte di consenso ai cookie: alcuni plugin per banner di consenso (come Complianz o CookieYes) memorizzano lo stato di consenso del visitatore in localStorage invece che in un cookie, sebbene l'uso di un cookie sia più comune.
• Stato dell'interfaccia di amministrazione: la dashboard di amministrazione di WordPress stessa utilizza entrambi i meccanismi di archiviazione. Ad esempio, ricorda quali metabox sono collassati, quali colonne sono visibili nell'elenco dei post e se il menu di amministrazione è ripiegato.
• Buffer di analisi e tracciamento: alcuni script di analisi raggruppano gli eventi in localStorage e li inviano al server in gruppi per ridurre le richieste di rete.

Considerazioni sulla sicurezza

Web Storage è conveniente ma comporta reali compromessi di sicurezza che gli sviluppatori devono comprendere.

• Esposizione XSS: qualsiasi JavaScript in esecuzione sulla pagina può leggere localStorage e sessionStorage. Se un attaccante riesce a iniettare uno script tramite una vulnerabilità di cross-site scripting (XSS), può estrarre qualsiasi valore memorizzato. I cookie possono essere protetti con il flag HttpOnly, che blocca completamente l'accesso JavaScript. Non c'è protezione equivalente per Web Storage.
• Same-origin policy: l'archiviazione ha come ambito l'origine, il che significa che https://example.com non può leggere l'archiviazione di https://other.com. Tuttavia, qualsiasi script sulla stessa origine, inclusi gli script di terze parti che carichi (analytics, reti pubblicitarie, widget di chat), ha pieno accesso alla stessa archiviazione.
• Nessuna crittografia: i dati vengono memorizzati in chiaro su disco. Chiunque abbia accesso fisico al dispositivo, o malware in esecuzione sul dispositivo, può leggerli. Non memorizzare mai password, token o altre credenziali sensibili in Web Storage.
• Nessuna validazione lato server: poiché i dati vivono solo nel browser, un utente o uno script può modificarli liberamente. Non fare mai affidamento sui valori di Web Storage per decisioni di autorizzazione o sicurezza sul server.

Implicazioni GDPR e privacy

Ai sensi del GDPR e della direttiva ePrivacy, localStorage e sessionStorage sono trattati allo stesso modo dei cookie quando si tratta di requisiti di consenso. Il principio legale è neutro rispetto alla tecnologia: se memorizzi o leggi informazioni sul dispositivo di un utente per uno scopo che non è strettamente necessario al servizio che l'utente ha richiesto, hai bisogno del consenso. Ciò significa che un carrello WooCommerce memorizzato in localStorage è probabilmente "strettamente necessario" e non richiede consenso. Ma un ID di analisi memorizzato in localStorage per tracciare i visitatori di ritorno richiede assolutamente il consenso. Molti proprietari di siti trascurano questo aspetto perché gli strumenti di consenso ai cookie tradizionalmente si concentrano sui cookie, ma le autorità di regolamentazione hanno chiarito che le regole si applicano a tutte le tecnologie di archiviazione lato client.

Web Storage vs cookie: quando usare quale

• Usa i cookie: quando il server deve leggere il valore a ogni richiesta (ID di sessione, token di autenticazione), quando hai bisogno della protezione HttpOnly contro XSS, o quando hai bisogno di un controllo granulare sulla scadenza.
• Usa localStorage: quando devi conservare le preferenze lato client o memorizzare in cache i dati attraverso le sessioni, i dati non hanno bisogno di viaggiare verso il server e i dati non sono sensibili.
• Usa sessionStorage: quando i dati hanno bisogno di vivere solo per la durata di una singola sessione di scheda, come l'avanzamento di un wizard di modulo, lo stato temporaneo dell'interfaccia utente o i token di reindirizzamento monouso.

Confronto delle prestazioni

Leggere e scrivere su Web Storage è sincrono e avviene sul thread principale. Per piccole quantità di dati questo è veloce, di solito sotto un millisecondo. Ma se una pagina scrive o legge grandi quantità di dati a ogni interazione, può causare jank. I cookie, al contrario, aggiungono overhead in un modo diverso: aumentano la dimensione di ogni header di richiesta HTTP, rallentando ogni chiamata di rete. Per memorizzare un pugno di piccoli valori, entrambi gli approcci si comportano bene. Per dataset più grandi (decine di KB o più), considera IndexedDB, che è asincrono e non blocca il thread principale.

Come ispezionare l'archiviazione in DevTools

Ogni browser principale ti permette di ispezionare Web Storage. In Chrome DevTools (F12), vai alla scheda Application e cerca "Local Storage" e "Session Storage" nella barra laterale sinistra. Puoi vedere ogni coppia chiave-valore, modificare manualmente i valori ed eliminare elementi. Firefox ha un pannello simile sotto la scheda Storage. Questo è il modo più semplice per vedere esattamente cosa un sito WordPress memorizza nel tuo browser e per risolvere comportamenti imprevisti.

Cosa controlla InspectWP

InspectWP elenca tutte le voci di localStorage e sessionStorage impostate dal tuo sito WordPress durante la scansione. Questo ti dà un quadro chiaro di ciò che il tuo sito memorizza lato client, quali plugin sono responsabili e se alcune voci potrebbero sollevare preoccupazioni sulla privacy ai sensi delle regole GDPR o ePrivacy.