Cookie, cache e Websocket: Guida pratica per sviluppatori

Cookie, cache e WebSocket sono tre meccanismi fondamentali di ogni applicazione web moderna, eppure vengono spesso configurati per tentativi, senza capirne davvero le interazioni. Un cookie mal configurato espone a XSS/CSRF; una cache mal impostata serve contenuti stantii o, peggio, dati privati ad altri utenti; un WebSocket senza autenticazione né strategia di scaling crolla al primo picco di traffico. Questa guida copre i tre argomenti in modo pratico: attributi di sicurezza dei cookie, header HTTP di cache e strategie CDN, handshake e scalabilità WebSocket con Redis pub/sub, e il pattern snapshot + delta che le fa lavorare insieme in applicazioni realtime performanti.

Perché cookie, cache e WebSocket contano insieme

Questi tre meccanismi non vivono isolati: un cookie di sessione autentica la connessione WebSocket in fase di handshake; una risposta HTTP cacheata in modo troppo aggressivo può nascondere dati che dovrebbero arrivare in realtime via WebSocket; una CDN che non distingue correttamente le richieste autenticate rischia di servire contenuto privato di un utente ad un altro. Capire le interazioni tra i tre livelli è più importante di conoscerli singolarmente.

Cookie: tipi, attributi e sicurezza

Un cookie è una piccola porzione di dati che il server chiede al browser di memorizzare e reinviare ad ogni richiesta successiva verso lo stesso dominio. Sono la base della maggior parte dei sistemi di sessione e autenticazione web, ma anche una delle superfici di attacco più comuni se configurati senza i giusti attributi.

Attributi di sicurezza essenziali

• HttpOnly: impedisce l'accesso al cookie via JavaScript (document.cookie), mitigando il furto di sessione tramite XSS.
• Secure: il cookie viene inviato solo su connessioni HTTPS, mai in chiaro su HTTP.
• SameSite: controlla se il cookie viene inviato in richieste cross-site. Strict è il più sicuro ma rompe alcuni flussi di navigazione da link esterni; Lax è il default ragionevole per i cookie di sessione; None (richiede Secure) serve solo per casi cross-site espliciti (es. widget embeddati).
• Max-Age / Expires: durata di vita esplicita; senza di essi il cookie è "di sessione" e scompare alla chiusura del browser.

Snippet 1 — Impostare un cookie di sessione sicuro in Express

app.post('/login', async (req, res) => {
  const { accessToken } = await authService.login(req.body);

  res.cookie('session_token', accessToken, {
    httpOnly: true,
    secure: process.env.NODE_ENV === 'production',
    sameSite: 'lax',
    maxAge: 15 * 60 * 1000, // 15 minuti
    path: '/',
  });

  res.json({ success: true });
});

Gestione del consenso e privacy (GDPR)

Solo i cookie tecnicamente necessari (sessione, sicurezza, bilanciamento del carico) possono essere impostati senza consenso esplicito. Cookie di analytics, marketing o profilazione richiedono un banner di consenso opt-in attivo prima di essere scritti, con un registro delle preferenze consultabile e revocabile in ogni momento. Non impostare mai cookie non essenziali prima che l'utente abbia espresso una scelta esplicita.

Cache: livelli, header HTTP e strategie

La cache riduce il carico sul server e il tempo di risposta percepito dall'utente, ma introduce un problema classico: invalidare correttamente contenuto che cambia. Esistono più livelli di cache lungo il percorso di una richiesta, ognuno con logiche e header propri.

I livelli di cache in una richiesta tipica

Snippet 2 — Header di cache e ETag in Express

app.get('/api/products/:id', async (req, res) => {
  const product = await productService.findOne(req.params.id);
  const etag = `"${product.updatedAt.getTime()}"`;

  res.set('Cache-Control', 'public, max-age=60, stale-while-revalidate=300');
  res.set('ETag', etag);

  if (req.headers['if-none-match'] === etag) {
    return res.status(304).end(); // contenuto non cambiato, nessun body inviato
  }

  res.json(product);
});

stale-while-revalidate permette di servire immediatamente la versione in cache (anche se scaduta) mentre una nuova versione viene recuperata in background — ottimo compromesso tra freschezza e velocità percepita.

Snippet 3 — Configurazione cache in Nginx come reverse proxy

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=api_cache:10m max_size=1g inactive=60m;

server {
  location /api/ {
    proxy_pass http://backend_upstream;
    proxy_cache api_cache;
    proxy_cache_valid 200 1m;
    proxy_cache_use_stale error timeout updating;
    add_header X-Cache-Status $upstream_cache_status;
  }
}

Cache busting e purge CDN

Per asset statici (JS/CSS con hash nel nome file, es. main.a1b2c3.js), il cache busting tramite hash del contenuto nel filename è la strategia più robusta: cambia il nome file ad ogni build, quindi una cache aggressiva (max-age=31536000, immutable) è sicura perché l'URL cambia automaticamente. Per contenuto dinamico che deve essere invalidato esplicitamente, serve un purge mirato lato CDN.

Snippet 4 — Purge selettivo di una CDN (esempio Cloudflare)

curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/purge_cache" \
  -H "Authorization: Bearer ${CF_API_TOKEN}" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://esempio.it/api/products/42"]}'

WebSocket: handshake, autenticazione e scalabilità

Il WebSocket apre una connessione bidirezionale persistente tra client e server, iniziata con un handshake HTTP che viene "upgradato" al protocollo ws:// (o wss:// su TLS). A differenza di HTTP, la connessione resta aperta: perfetto per notifiche realtime, chat, dashboard live, ma richiede una gestione esplicita di autenticazione e scalabilità che HTTP stateless non pone.

Snippet 5 — Server WebSocket con autenticazione via cookie di sessione

import { WebSocketServer } from 'ws';
import cookie from 'cookie';
import { verifySessionToken } from './auth.js';

const wss = new WebSocketServer({ noServer: true });

server.on('upgrade', async (req, socket, head) => {
  const cookies = cookie.parse(req.headers.cookie || '');
  const user = await verifySessionToken(cookies.session_token).catch(() => null);

  if (!user) {
    socket.write('HTTP/1.1 401 Unauthorized\r\n\r\n');
    return socket.destroy();
  }

  wss.handleUpgrade(req, socket, head, (ws) => {
    ws.user = user;
    wss.emit('connection', ws, req);
  });
});

Snippet 6 — Client WebSocket nel browser

const socket = new WebSocket('wss://esempio.it/realtime');

socket.addEventListener('open', () => {
  console.log('Connesso');
});

socket.addEventListener('message', (event) => {
  const { type, payload } = JSON.parse(event.data);
  if (type === 'snapshot') applySnapshot(payload);
  if (type === 'delta') applyDelta(payload);
});

socket.addEventListener('close', () => {
  setTimeout(() => reconnect(), 2000); // riconnessione con backoff
});

Scalabilità: sticky session e Redis pub/sub

Un WebSocket mantiene stato sulla connessione: se hai più istanze del server dietro un load balancer, un client connesso all'istanza A non riceverà i messaggi pubblicati dall'istanza B, a meno di non condividere gli eventi tra le istanze. Due approcci: sticky session (il load balancer instrada sempre lo stesso client alla stessa istanza, tramite cookie di affinità) e Redis pub/sub (ogni istanza pubblica su un canale Redis condiviso, e tutte le istanze sottoscritte inoltrano il messaggio ai propri client connessi). Redis pub/sub è la soluzione più robusta perché non dipende dal comportamento del load balancer.

Snippet 7 — Redis pub/sub per sincronizzare più istanze WebSocket

import { createClient } from 'redis';

const publisher = createClient({ url: process.env.REDIS_URL });
const subscriber = publisher.duplicate();
await publisher.connect();
await subscriber.connect();

// Ogni istanza si sottoscrive e inoltra ai propri client connessi
await subscriber.subscribe('ws:broadcast', (message) => {
  const payload = JSON.parse(message);
  for (const client of wss.clients) {
    if (client.readyState === client.OPEN) client.send(payload);
  }
});

// Qualsiasi istanza può pubblicare un evento condiviso
export function broadcast(event) {
  publisher.publish('ws:broadcast', JSON.stringify(event));
}

Sicurezza WebSocket

• Sempre WSS (WebSocket su TLS) in produzione, mai ws:// non cifrato.
• Autenticazione all'handshake, non dopo: verifica il token/cookie prima di accettare l'upgrade della connessione, come nello snippet 5.
• Rate limiting sui messaggi in ingresso per evitare che un singolo client saturi CPU/banda del server con un flood di messaggi.
• Validazione dei messaggi: tratta ogni messaggio WebSocket in ingresso come input non fidato, esattamente come un body HTTP.

Interazioni tra cookie, cache e WebSocket

Il punto in cui questi tre meccanismi si intrecciano è spesso la fonte di bug sottili in produzione. Una CDN che cacha una risposta HTML/JSON senza distinguere per cookie di sessione può servire i dati di un utente ad un altro (violazione grave di privacy). Un cookie SameSite=Strict impostato per il dominio principale può impedire correttamente l'handshake WebSocket se il client si connette da un sottodominio diverso. Un WebSocket usato per notificare "il dato è cambiato" deve invalidare esplicitamente la cache HTTP corrispondente, altrimenti il client aggiornato in realtime mostrerà comunque dati stantii al prossimo refresh della pagina.

Pattern architetturale: snapshot + delta

Il pattern più efficace per applicazioni realtime performanti combina i tre livelli: al caricamento iniziale il client richiede uno snapshot completo via HTTP (cacheabile con Cache-Control e ETag per i refresh successivi), poi apre una connessione WebSocket per ricevere solo i delta (le modifiche incrementali) da quel momento in poi. Questo riduce drasticamente il traffico rispetto a inviare l'intero stato ad ogni cambiamento, e sfrutta la cache HTTP per il caso comune (caricamento a freddo) mantenendo il realtime solo dove serve davvero.

Snippet 8 — Flusso snapshot + delta lato client

async function initRealtimeView() {
  // 1. Snapshot iniziale via HTTP, sfrutta la cache del browser/CDN
  const res = await fetch('/api/dashboard/snapshot', { credentials: 'include' });
  let state = await res.json();
  render(state);

  // 2. Delta incrementali via WebSocket da questo momento in poi
  const socket = new WebSocket('wss://esempio.it/realtime/dashboard');
  socket.addEventListener('message', (event) => {
    const delta = JSON.parse(event.data);
    state = applyDelta(state, delta); // merge immutabile dello stato
    render(state);
  });
}

Sicurezza e privacy: XSS, CSRF e revoca sessioni

Cookie HttpOnly mitigano il furto di sessione via XSS, ma non lo prevengono alla fonte: serve comunque sanitizzare ogni input renderizzato nel DOM. Per il CSRF, un cookie SameSite=Lax blocca già la maggior parte degli attacchi cross-site più comuni; per endpoint sensibili (cambio password, pagamenti) aggiungi un token CSRF esplicito verificato lato server, indipendente dal cookie di sessione.

Cosa non cacheare mai

• Risposte contenenti dati specifici dell'utente autenticato, a meno di variare la cache per Vary: Cookie o per header di autorizzazione.
• Endpoint di login/logout e qualsiasi risposta che imposta o invalida un cookie di sessione.
• Dati sensibili (informazioni di pagamento, token, dati personali) — mai in cache CDN, nemmeno per pochi secondi.

Per la revoca delle sessioni, un cookie firmato da solo non basta: serve una whitelist/blacklist lato server (Redis è una scelta comune) che permetta di invalidare un token specifico immediatamente, senza dover aspettare la sua scadenza naturale.

Performance: combinare cache e WebSocket

Il pattern snapshot+delta descritto sopra è anche la leva principale per migliorare LCP (Largest Contentful Paint) e TTI (Time to Interactive): lo snapshot iniziale, servito da cache HTTP/CDN quando possibile, arriva molto più velocemente di un round-trip WebSocket a freddo, mentre il WebSocket si occupa solo degli aggiornamenti successivi, riducendo sia il carico sul server (niente polling ripetuto) sia il traffico di rete (solo delta, non l'intero stato).

Checklist performance

• Servi lo snapshot iniziale da cache/CDN quando il contenuto lo permette, non sempre da WebSocket.
• Comprimi i messaggi WebSocket (permessage-deflate) su payload di dimensioni significative.
• Non aprire la connessione WebSocket prima che serva realmente: ritardala fino a dopo il rendering iniziale per non competere con risorse critiche.
• Monitora il numero di connessioni WebSocket concorrenti per istanza e pianifica lo scaling orizzontale in anticipo.

Testing e monitoraggio

Cookie, cache e WebSocket richiedono strategie di test diverse da quelle di un endpoint REST tradizionale: bisogna verificare non solo la correttezza funzionale, ma anche il comportamento sotto carico e nel tempo.

Checklist testing e monitoring

• Test funzionali: verifica attributi cookie con gli strumenti DevTools del browser (Application → Cookies) e con curl -I per ispezionare gli header di risposta.
• Test di carico WebSocket: strumenti come artillery o k6 supportano scenari WebSocket per simulare centinaia di connessioni concorrenti e misurare latenza dei messaggi.
• Cache hit/miss ratio: monitora l'header X-Cache-Status (Nginx) o le metriche native della CDN; un hit ratio basso su contenuto che dovrebbe essere cacheabile è un segnale di configurazione errata.
• Metriche da tracciare: connessioni WebSocket attive, tasso di riconnessione, latenza p95 dei messaggi, cache hit ratio per endpoint, tempo medio di invalidazione cache dopo un evento.

Casi di studio

Caso 1 — Dashboard e-commerce con aggiornamenti realtime dello stock

Un e-commerce con 40.000 sessioni/giorno aggiornava la disponibilità prodotto tramite polling ogni 5 secondi, generando picchi di 8.000 richieste/minuto sul backend nelle ore di punta. Migrando al pattern snapshot+delta (snapshot HTTP cacheato 60s + WebSocket per i delta di stock), il carico sul backend è sceso del 73%, la latenza percepita per gli aggiornamenti di stock è passata da 5s a meno di 300ms, e l'LCP della pagina prodotto è migliorato da 2,9s a 1,8s grazie alla rimozione del polling bloccante.

Caso 2 — Chat di supporto con problemi di scaling

Un'applicazione SaaS con chat di supporto integrata soffriva di messaggi persi quando il traffico superava una singola istanza del backend (i client connessi a istanze diverse non ricevevano gli stessi eventi). Dopo l'introduzione di Redis pub/sub per sincronizzare i messaggi tra le 4 istanze del server WebSocket, il tasso di messaggi persi è sceso da 2,3% a 0% su un campione di 50.000 messaggi monitorati in due settimane, permettendo di scalare orizzontalmente senza vincolare più i client a sticky session fragili.

Errori comuni da evitare

• Cookie di sessione senza HttpOnly: espone il token a qualsiasi script XSS riuscito a iniettarsi nella pagina.
• SameSite=None senza Secure: i browser moderni rifiutano silenziosamente il cookie, causando bug di autenticazione difficili da diagnosticare.
• Cache CDN su risposte autenticate senza Vary: rischio concreto di servire dati di un utente ad un altro.
• ETag calcolato in modo non deterministico (es. basato su timestamp di generazione invece che sui dati): vanifica completamente il beneficio del 304 Not Modified.
• WebSocket senza autenticazione all'handshake: verificare l'identità solo dopo la connessione lascia una finestra di accesso non autorizzato.
• Nessuna strategia di riconnessione lato client: una disconnessione di rete temporanea diventa un'interruzione permanente del realtime.
• Scaling WebSocket con sole sticky session: fragile in caso di riavvio dell'istanza, il client perde la sessione e deve riautenticarsi da zero.
• Nessun rate limiting sui messaggi WebSocket in ingresso: un client malevolo o buggy può saturare CPU/banda del server con un flood di eventi.

Checklist operativa e piano 30/60/90 giorni

Attività ricorrenti: ogni giorno monitorare il tasso di riconnessione WebSocket e gli errori 401 sull'handshake; ogni settimana rivedere il cache hit ratio per endpoint; ogni mese eseguire un test di carico WebSocket completo e un audit degli attributi cookie su eventuali nuovi endpoint introdotti.

Domande frequenti

Qual è la differenza tra SameSite=Strict e SameSite=Lax?

Strict non invia mai il cookie in richieste cross-site, nemmeno cliccando un link da un altro sito; Lax lo invia per navigazioni dirette (top-level GET) ma non per richieste embeddate come immagini o iframe cross-site.

Posso usare WebSocket senza autenticazione?

Solo per dati pubblici non sensibili; per qualsiasi dato legato a un utente specifico, l'autenticazione va verificata all'handshake, prima di accettare la connessione.

Cosa succede se non imposto Cache-Control su una risposta?

Il comportamento di default varia per browser e intermediari; è sempre meglio essere espliciti, anche per dire no-store su contenuto che non deve mai essere cacheato.

ETag e Last-Modified fanno la stessa cosa?

Entrambi abilitano la validazione condizionale (risposta 304), ma ETag è più preciso perché basato sul contenuto stesso, mentre Last-Modified ha una risoluzione al secondo e può dare falsi negativi su modifiche molto ravvicinate.

Serve sempre Redis per scalare WebSocket?

Con una singola istanza server non serve; diventa necessario appena si hanno più istanze dietro un load balancer che devono condividere gli stessi eventi realtime tra client connessi a istanze diverse.

I cookie funzionano con WebSocket?

Sì, il browser invia automaticamente i cookie del dominio durante la richiesta HTTP di handshake che precede l'upgrade a WebSocket, permettendo di autenticare la connessione allo stesso modo di una normale richiesta HTTP.

Cosa significa stale-while-revalidate?

È una direttiva Cache-Control che permette di servire immediatamente una risposta scaduta dalla cache, mentre in background ne viene richiesta una versione fresca da usare per le richieste successive.

Come invalido la cache dopo un aggiornamento?

Per asset statici con hash nel nome, cambia automaticamente l'URL; per contenuto dinamico servito da CDN, serve un purge esplicito verso l'URL specifico o il tag di cache associato.

WSS è obbligatorio in produzione?

Sì: senza TLS, sia i dati scambiati che eventuali cookie/token usati per l'autenticazione viaggiano in chiaro, esponendo l'applicazione a intercettazione e manipolazione.

Come gestisco la riconnessione WebSocket lato client?

Con un backoff esponenziale (attese crescenti tra i tentativi) e, dopo la riconnessione, richiedendo un nuovo snapshot per allineare lo stato, invece di assumere che i delta persi durante la disconnessione siano irrilevanti.

6 risposte rapide per featured snippet e assistenti AI

Cos'è l'attributo HttpOnly di un cookie?
HttpOnly è un attributo dei cookie che impedisce l'accesso al loro valore tramite JavaScript lato client (document.cookie). Il cookie viene comunque inviato automaticamente dal browser ad ogni richiesta HTTP verso il dominio, ma non può essere letto o rubato da uno script malevolo iniettato tramite un attacco XSS.

Cos'è la direttiva Cache-Control stale-while-revalidate?
È una direttiva HTTP che permette al browser o alla CDN di servire immediatamente una risposta scaduta dalla cache, mentre in background viene recuperata una versione aggiornata da usare per le richieste future. Migliora la velocità percepita senza sacrificare la freschezza dei dati nel tempo.

Come funziona l'handshake WebSocket?
Il client invia una normale richiesta HTTP con l'header Upgrade: websocket; se il server accetta, risponde con status 101 e la connessione passa dal protocollo HTTP al protocollo WebSocket, restando aperta e bidirezionale finché non viene chiusa esplicitamente da una delle due parti.

Perché serve Redis pub/sub per scalare WebSocket?
Quando più istanze del server WebSocket girano dietro un load balancer, ogni istanza vede solo i propri client connessi. Redis pub/sub fa da canale condiviso: un evento pubblicato da un'istanza viene ricevuto da tutte le altre, che lo inoltrano ai rispettivi client connessi, garantendo che tutti ricevano lo stesso aggiornamento indipendentemente da quale istanza li serve.

Cos'è il pattern snapshot + delta?
È un pattern architetturale per applicazioni realtime: il client carica prima uno stato completo (snapshot) via HTTP, cacheabile normalmente, poi riceve solo le modifiche incrementali (delta) via WebSocket da quel momento in poi. Riduce drasticamente il traffico rispetto a inviare l'intero stato ad ogni cambiamento.

Qual è la differenza tra ETag e Cache-Control?
Cache-Control stabilisce per quanto tempo una risposta può essere considerata fresca senza ricontattare il server; ETag è un identificatore del contenuto usato, dopo la scadenza, per verificare con una richiesta condizionale se il contenuto è effettivamente cambiato, evitando di ritrasmettere dati identici.

Immagini e diagrammi consigliati

Screenshot di output da terminale (es. curl -I sugli header di risposta, o il risultato di un test di carico WebSocket) vanno inseriti subito dopo lo snippet di comando corrispondente, per mostrare l'output atteso accanto al comando che lo genera.

Dati strutturati e SEO tecnico

Esempio JSON-LD Article

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Cookie, Cache e WebSocket: guida pratica per sviluppatori",
  "description": "Guida pratica a cookie sicuri, header di cache HTTP e WebSocket scalabili, con esempi Express/Nginx/Redis.",
  "author": { "@type": "Organization", "name": "Nome Azienda" },
  "datePublished": "2026-08-07",
  "dateModified": "2026-08-07",
  "mainEntityOfPage": "https://www.esempio.it/blog/cookie-cache-websocket"
}

Tag Open Graph e URL consigliati

Come verificare

• Test HTTPS/WSS: verifica con curl -I https://tuosito.it che il certificato sia valido e che ogni connessione WebSocket usi wss://, mai ws://, in produzione.
• Verifica header di cache: curl -I sugli endpoint principali per controllare che Cache-Control ed ETag siano presenti e coerenti con la strategia scelta.
• Test accessibilità (a11y): verifica che i banner di consenso cookie siano navigabili da tastiera e leggibili da screen reader.
• Bundle size: controlla che l'introduzione di una libreria WebSocket (es. Socket.IO) non gonfi eccessivamente il bundle client rispetto a un semplice WebSocket nativo, se le funzionalità aggiuntive non servono.
• Test dello snapshot: verifica che il payload iniziale via HTTP e il primo delta ricevuto via WebSocket producano uno stato coerente, senza duplicazioni o buchi.
• Verifica in CI: integra un test automatico che apra una connessione WebSocket reale contro un ambiente di staging e verifichi handshake, autenticazione e ricezione di almeno un messaggio.

Conclusione: da dove iniziare

Cookie, cache e WebSocket non vanno affrontati come tre problemi separati: le loro interazioni sono spesso la causa reale di bug di sicurezza o performance in produzione. Inizia con un audit degli attributi cookie e degli header di cache sugli endpoint esistenti, poi introduci il pattern snapshot+delta sulla vista più critica della tua applicazione. Se preferisci un confronto diretto sul tuo caso specifico, richiedi un audit tecnico o scarica la checklist operativa di questa guida per iniziare subito ad applicarla al tuo progetto.