--- title: "Cookie HttpOnly vs LocalStorage: dove salvare i token" description: "LocalStorage espone i token di autenticazione a qualsiasi script della pagina, XSS compreso. Perché i cookie HttpOnly chiudono la falla, con esempio in Nuxt 3." url: "https://volcanicminds.com/insights/cookie-vs-localstorage-security-guide" lang: "it-it" type: "second_level_page" updated: "2026-09-03" alternate: "https://volcanicminds.com/en/insights/cookie-vs-localstorage-security-guide" --- # Non solo AI nel 2026: Cookie vs LocalStorage ## Guida alla sicurezza dei Token Visto il periodo, immaginiamo di avere rilasciato la nostra nuova piattaforma SaaS potenziata dall'AI. L'interfaccia è reattiva, i modelli rispondono in millisecondi (complimenti!), e gli investitori sono entusiasti. Ma mentre il team festeggia, uno script di tre righe sta silenziosamente inviando quel singolo token di accesso verso un server anonimo. Nessun allarme suona. Nessun firewall blocca la richiesta. Perché? Perché quel token era salvato nel **LocalStorage**. Ecco un classico problema della **Web Security**. Se pensi che "_basti sanitizzare gli input_" per essere al sicuro, questo articolo forse ti aiuterà a capire perché non è così. ## La comodità è nemica della sicurezza Perché continuiamo a vedere tutorial che consigliano **_localStorage.setItem('accessToken', token**)_? La risposta è semplice: è incredibilmente comodo e veloce da implementare. Non devi gestire CORS, non devi preoccuparti dei domini, funziona e basta. Ma in un'architettura **Zero Trust Architecture**, la comodità si paga a caro prezzo. **LocalStorage** ha (purtroppo) un difetto di progettazione fatale per i dati sensibili: è accessibile da _qualsiasi_ codice JavaScript che gira nella tua pagina. Questo include: - La tua applicazione Web (ad es. Vue/Nuxt, React/Next, Angular, ..). - Le librerie di terze parti (analytics, chat widget, social pixel). - Eventuale codice malevolo iniettato tramite **XSS (Cross-Site Scripting)**. Se un attaccante riesce a eseguire JS nella tua pagina (XSS), leggere il LocalStorage è banale quanto leggere una variabile. ## HttpOnly: L'unica barriera reale La soluzione corretta non è cercare di "blindare" il LocalStorage, ma usare uno storage che il JavaScript _non può_ leggere: i **Cookie HttpOnly**. Quando un cookie è flaggato come HttpOnly, il browser lo nasconde al motore JavaScript (document.cookie non lo mostrerà), ma continua a inviarlo automaticamente a ogni richiesta verso il server di origine. Questo riduce drasticamente la superficie di attacco: anche in presenza di una vulnerabilità XSS, l'attaccante non può rubare il token così facilmente. ### La Strategia: Cookie Strict Mode Sebbene il **Volcanic Backend** supporti nativamente diverse modalità di autenticazione (inclusi i classici Bearer Token via Header, utili per app mobile o chiamate server-to-server), per le Web App Enterprise **conviene attivare tassativamente la modalità Cookie**. Questa configurazione sposta la responsabilità della persistenza dal codice client (vulnerabile) al browser (protetto), sfruttando due barriere fondamentali: 1. **HttpOnly**: Il token non è accessibile via JavaScript. Nemmeno dal _tuo_ codice. 1. **Secure & SameSite**: Il browser invia il token solo su connessioni cifrate e solo verso il dominio di origine, prevenendo CSRF. In questo scenario, il LocalStorage rimane vuoto (o usato solo per preferenze UI), e l'autenticazione fluisce in modo trasparente e sicuro. ## Implementazione concettuale in Nuxt 3 Vediamo come implementare questo pattern (in parte) sfruttando i composables di Nuxt 3 e il server engine Nitro. ### 1. Login Sicuro (Server Side) In un progetto **Volcanic Backend**, la gestione dei cookie avviene nel controller, sfruttando l'architettura basata su Fastify. Definiamo prima la rotta in src/api/auth/routes.ts: ```javascript // src/api/auth/routes.ts export default { config: { controller: "controller", enable: true, tags: ["Auth"], }, routes: [ { method: "POST", path: "/login", handler: "auth.login", config: { description: "Secure Login with HttpOnly Cookie", response: { 200: { type: "object", properties: { accessToken: { type: "string" } }, }, }, }, }, ], }; ``` E poi implementiamo la logica nel controller src/api/auth/controller/auth.ts: ```javascript // src/api/auth/controller/auth.ts import { FastifyReply, FastifyRequest } from "@volcanicminds/backend"; export async function login(req: FastifyRequest, reply: FastifyReply) { const { username, password } = req.body as any; // ... es validazione user ... // const user = await authService.validate(username, password) const token = generateAccessToken(user.id); // Salva il token in un cookie sicuro reply.setCookie("token", token, { httpOnly: true, secure: process.env.NODE_ENV === "production", sameSite: "strict", path: "/", maxAge: 60 * 60 * 24, // 1 giorno }); // Il client non ha bisogno di ricevere il token nel body! return { success: true, user: { id: user.id, username: user.username } }; } ``` ### 2. Session Management (Client Side) Lato frontend, **non dobbiamo fare nulla con il token**. Non lo salviamo, non lo leggiamo. Quando facciamo una chiamata API con $fetch (o useFetch), il browser allegherà automaticamente il cookie. ```javascript // composables/useAuth.ts export const useAuth = () => { const user = useState("user", () => null); const login = async (credentials: any) => { // La risposta imposterà il cookie automaticamente const data = await $fetch("/api/auth/login", { method: "POST", body: credentials, }); // Aggiorniamo solo lo stato utente per la UI user.value = data.user; }; return { user, login }; }; ``` Questo approccio garantisce che il segreto (il token di accesso) sia **invisibile** al codice JavaScript. Se anche uno script malevolo provasse a leggere document.cookie, troverebbe una stringa vuota (grazie a HttpOnly). E senza token, non può impersonare l'utente fuori dal browser della vittima. ## Non usiamo solo librerie, progettiamo architetture In Volcanic Minds sviluppiamo piattaforme complesse (Enterprise ERP & Dashboard). Per noi la sicurezza non è una feature, è il punto di partenza. Non ci limitiamo a usare librerie, progettiamo architetture resilienti ed è per questo che nel tempo è nato il **[Volcanic Backen**d](https://github.com/volcanicminds/volcanic-backend). Un framework open-source che integra nativamente queste best practices di sicurezza, permettendo di concentrarsi sulla logica di business sapendo di poggiare su fondamenta solide. ## Conclusione La sicurezza da sempre ma ancor più in questo 2026 non riguarda più solo l'HTTPS o le password complesse. Riguarda l'architettura dei dati nel client e fra client e server. Spostare i token dal LocalStorage ai Cookie HttpOnly è uno di quegli investimenti **a costo zero** che alzano drasticamente l'asticella che devono superare potenziali attaccanti. ### Sei sicuro che la tua Web App sia a prova di XSS? Se hai dubbi sulla sicurezza della tua piattaforma, in Volcanic Minds offriamo audit architetturali specifici per individuare e chiudere queste falle prima che sia troppo tardi. - [Richiedi una Security Review gratuita](https://volcanicminds.com/contacts) ## Le domande che restano Quello che si chiede chi ha capito il pattern e deve applicarlo ### C'è un caso in cui il LocalStorage va bene per un token? Non è mai consigliato per un token che dà accesso a dati veri. L'eccezione a cui si pensa è l'app mobile o la chiamata server-to-server, dove non c'è un browser e non c'è superficie XSS: lì un Bearer token in header va benissimo. Dentro un browser, qualsiasi script della pagina può leggere il LocalStorage, incluse le librerie di terze parti che non avete controllato. ### Abbiamo già i token in LocalStorage: da dove si comincia? Si sposta il token in un cookie HttpOnly e si invalidano le sessioni esistenti, in quest'ordine. Ruotare i token senza cambiare dove stanno significa solo rimettere a zero il contatore sulla stessa esposizione. La modifica al frontend è di solito più piccola del previsto: una volta che il cookie viaggia da solo, il client smette del tutto di gestire il token. ### I cookie HttpOnly proteggono anche dal CSRF? Non da soli: HttpOnly chiude la lettura via XSS, non la richiesta cross-site. Per quella serve SameSite, impostato su strict o lax a seconda dei flussi che vi servono, insieme ai controlli sull'origine per le richieste che modificano stato. Sono due attacchi diversi e servono entrambi i flag.