Non solo AI nel 2026:
Cookie vs LocalStorage

Macro artistica di pannelli di vetro scuro sovrapposti con riflessi arancioni vulcanici sui bordi.

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:

HttpOnly: Il token non è accessibile via JavaScript. Nemmeno dal tuo codice.
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:

// 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 } };
}

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.

// 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 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

Tag: Development

: 17 gennaio 2026

Non solo AI nel 2026:Cookie vs LocalStorage