Non solo AI nel 2026:
Cookie vs LocalStorage
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ì.
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:
Se un attaccante riesce a eseguire JS nella tua pagina (XSS), leggere il LocalStorage è banale quanto leggere una variabile.
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.
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:
In questo scenario, il LocalStorage rimane vuoto (o usato solo per preferenze UI), e l'autenticazione fluisce in modo trasparente e sicuro.
Vediamo come implementare questo pattern (in parte) sfruttando i composables di Nuxt 3 e il server engine Nitro.
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:
// 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:
// 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 } };
}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.
// 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.
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 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.
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.
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.
: 17 gennaio 2026