Un attacco CSRF (Cross-Site Request Forgery) sfrutta la sessione attiva di un utente per eseguire azioni che l’utente non ha mai voluto: cambiare la password, trasferire denaro, eliminare un account. Il browser allega automaticamente i cookie di sessione a ogni richiesta verso il tuo dominio, anche quando la richiesta parte da un sito malevolo. Senza una protezione CSRF, la tua applicazione Node.js non riesce a distinguere una richiesta legittima da una falsificata.<\/p>\n\n\n\n
Questo tutorial ti guida in 12 step concreti verso una protezione CSRF solida su Express 5<\/strong>, usando il pattern Signed Double Submit Cookie con il pacchetto Un attacco CSRF funziona perch\u00e9 l’autenticazione basata su cookie \u00e8 ambientale<\/em>. Quando ti autentichi su Ecco la versione pi\u00f9 semplice dell’attacco. Una pagina ostile contiene un form nascosto che si invia da solo al caricamento:<\/p>\n\n\n\n La vittima non clicca nulla. Il form si invia automaticamente, il browser allega il cookie di sessione e il server, senza una protezione CSRF, esegue il trasferimento come se fosse legittimo. Lo stesso schema si realizza con un tag La difesa fondamentale \u00e8 un segreto che il sito malevolo non pu\u00f2 conoscere n\u00e9 leggere: un token CSRF<\/strong> imprevedibile, legato alla sessione, che deve accompagnare ogni richiesta che cambia stato (POST, PUT, PATCH, DELETE). Il browser invia automaticamente i cookie, ma non pu\u00f2 fabbricare un token valido per un dominio diverso dal proprio, e la Same-Origin Policy impedisce a uno script cross-site di leggere il token. Su questo principio si basa l’intero tutorial.<\/p>\n\n\n\n Prima di scrivere codice, allinea l’ambiente. Le versioni qui sotto sono lo standard di riferimento a giugno 2026. Usa una versione LTS di Node.js: le versioni dispari non ricevono supporto a lungo termine e non vanno in produzione.<\/p>\n\n\n\n Verifica subito la versione di Node con Una nota importante sul pacchetto storico Esistono tre famiglie di difesa contro gli attacchi CSRF, pi\u00f9 l’attributo cookie In questo tutorial implementiamo il Signed Double Submit Cookie<\/strong> tramite Crea la cartella del progetto e inizializza npm. Useremo i moduli ES ( Aggiungi uno script di avvio nel Crea ora Avvia con Il pattern Signed Double Submit ha bisogno di due cose: la capacit\u00e0 di leggere e scrivere cookie, e un segreto HMAC stabile con cui firmare i token. Registra Il segreto CSRF non deve mai essere scritto in chiaro nel codice. Generane uno forte (almeno 32 byte, 256 bit) e caricalo da una variabile d’ambiente. In sviluppo va bene generarlo a runtime, ma in produzione il segreto deve essere fisso e persistente, altrimenti tutti i token diventano invalidi a ogni riavvio del server.<\/p>\n\n\n\n Salva il valore generato in un file Ora il cuore della protezione. La funzione Analizziamo le opzioni principali. Le La funzione Applica il middleware La rotta Un principio da non violare mai: le rotte GET devono restare sicure e idempotenti. Se hai una rotta come Per un form tradizionale con rendering server-side, inietta il token in un campo nascosto. Aggiungiamo una rotta che genera il token e lo inserisce nell’HTML. Useremo template literals per semplicit\u00e0, ma in un progetto reale lo passeresti al tuo motore di template (EJS, Pug, Handlebars).<\/p>\n\n\n\n Quando l’utente invia il form, il browser allega sia il cookie del token (firmato HMAC) sia il valore nel campo Genera sempre un token fresco al rendering della pagina. Non riutilizzare lo stesso token statico tra pagine diverse e non incorporarlo nell’URL: gli URL finiscono nei log, nella cronologia del browser e nell’header Le Single Page Application (React, Vue, Angular) non usano form server-side. Recuperano il token da un endpoint dedicato all’avvio e lo allegano a ogni richiesta che cambia stato tramite un header personalizzato. Questo approccio \u00e8 pi\u00f9 sicuro dei campi nascosti perch\u00e9 gli header personalizzati non possono essere impostati da uno script cross-site senza superare la Same-Origin Policy.<\/p>\n\n\n\n L’opzione Conserva il token nello stato dell’applicazione (variabile di modulo, store Redux\/Pinia), non in Un token CSRF \u00e8 la difesa primaria, ma OWASP raccomanda di non affidarsi a un solo controllo. Aggiungiamo tre barriere complementari che rendono l’attacco molto pi\u00f9 difficile anche in caso di errore di configurazione.<\/p>\n\n\n\n Imposta Come difesa secondaria, verifica l’header Applica Senza HTTPS, un attaccante in posizione di rete pu\u00f2 leggere il cookie del token e l’intera protezione crolla. In produzione, imponi HTTPS, attiva il flag Quando un token manca o non \u00e8 valido, Lato client, intercetta la risposta 403 e gestiscila con eleganza: richiedi un nuovo token e, se opportuno, riprova la richiesta una sola volta. Non mostrare mai il messaggio di errore grezzo all’utente finale e non loggare il valore del token nei log applicativi, perch\u00e9 renderebbe vana la sua segretezza.<\/p>\n\n\n\n Una protezione non testata non \u00e8 una protezione. Verifichiamo tre scenari: una richiesta senza token deve fallire, una con token valido deve passare, e cookie e token incoerenti devono essere respinti. Usiamo Il primo comando deve restituire 403, confermando che le richieste prive di token vengono bloccate. Il terzo deve restituire 200, confermando che una richiesta legittima con cookie e header coerenti passa. Se inverti i due, ad esempio fornendo il token ma non il cookie (o viceversa), la richiesta deve fallire: il pattern Double Submit richiede entrambi.<\/p>\n\n\n\n Per un test automatizzato, puoi scrivere una suite con Supertest che esegue questi tre scenari in un test di integrazione. Includi sempre il caso negativo (token mancante) tra i test, perch\u00e9 \u00e8 quello che garantisce che la protezione sia davvero attiva e non solo presente nel codice.<\/p>\n\n\n\n Ecco l’ La struttura del progetto resta minima: Anche con la libreria giusta, alcuni errori ricorrenti vanificano la protezione. Ecco i sei pi\u00f9 diffusi e come evitarli.<\/p>\n\n\n\n Quando la protezione CSRF non si comporta come previsto, la causa \u00e8 quasi sempre una di queste. La tabella collega il sintomo alla causa e alla soluzione.<\/p>\n\n\n\ncsrf-csrf<\/code>. Tempo stimato: circa 30 minuti. Alla fine avrai un progetto completo e funzionante, con form HTML protetti, una variante per SPA (React, Vue, Angular), gestione degli errori, test di attacco simulato e una checklist di difese a strati allineata alla OWASP CSRF Prevention Cheat Sheet 2025.<\/p>\n\n\n\nCos’\u00e8 un attacco CSRF e perch\u00e9 colpisce ogni app Node.js<\/h2>\n\n\n\n
banca.it<\/code>, il server imposta un cookie di sessione. Da quel momento il browser invia quel cookie a banca.it<\/code> in ogni richiesta, indipendentemente da quale pagina abbia originato la richiesta. Se visiti una pagina malevola mentre la tua sessione su banca.it<\/code> \u00e8 ancora valida, quella pagina pu\u00f2 inviare di nascosto una richiesta POST verso banca.it<\/code> e il cookie viaggia insieme alla richiesta.<\/p>\n\n\n\n<!-- Pagina malevola: evil.example\/regalo.html -->\n<body onload=\"document.forms[0].submit()\">\n <form action=\"https:\/\/banca.it\/trasferisci\" method=\"POST\">\n <input type=\"hidden\" name=\"importo\" value=\"5000\">\n <input type=\"hidden\" name=\"destinatario\" value=\"IT60-CONTO-ATTACCANTE\">\n <\/form>\n<\/body><\/code><\/pre>\n\n\n\n<img><\/code> per le richieste GET non protette, motivo per cui le richieste GET non devono mai modificare lo stato del server.<\/p>\n\n\n\nPrerequisiti e versioni richieste<\/h2>\n\n\n\n
Componente<\/th> Versione consigliata (2026)<\/th> Ruolo nel progetto<\/th><\/tr><\/thead> Node.js<\/td> 22 LTS (o 24 LTS)<\/td> Runtime; modulo crypto<\/code> nativo per HMAC<\/td><\/tr>Express<\/td> 5.x<\/td> Framework HTTP e middleware<\/td><\/tr> csrf-csrf<\/td> 4.x<\/td> Pattern Signed Double Submit Cookie<\/td><\/tr> cookie-parser<\/td> 1.4.x<\/td> Lettura e firma dei cookie<\/td><\/tr> express-session (opzionale)<\/td> 1.18.x<\/td> Sessioni lato server, se usate<\/td><\/tr> helmet (consigliato)<\/td> 8.x<\/td> Header di sicurezza HTTP<\/td><\/tr> npm<\/td> 10.x o superiore<\/td> Gestione dipendenze<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n node -v<\/code>. Se \u00e8 inferiore alla 22, aggiorna prima di proseguire: Express 5 richiede Node 18 o superiore e diverse correzioni di sicurezza sui cookie sono arrivate solo nelle versioni LTS recenti. Una conoscenza di base di JavaScript asincrono (Promise, async\/await<\/code>) e del modello richiesta\/risposta di Express \u00e8 data per scontata.<\/p>\n\n\n\ncsurf<\/code>: \u00e8 deprecato e abbandonato dal 2020. Non riceve aggiornamenti, non gestisce correttamente l’attributo SameSite<\/code> moderno e ha problemi noti. Non usarlo in nessun progetto nuovo. Il sostituto mantenuto \u00e8 csrf-csrf<\/code>, che useremo qui.<\/p>\n\n\n\nI tre pattern di protezione CSRF a confronto<\/h2>\n\n\n\n
SameSite<\/code> come barriera complementare. Capire le differenze ti permette di scegliere il pattern giusto per la tua architettura. Le applicazioni stateful con sessioni lato server tendono al Synchronizer Token Pattern; le API stateless e le SPA preferiscono il Double Submit Cookie firmato.<\/p>\n\n\n\nPattern<\/th> Come funziona<\/th> Stato lato server<\/th> Caso d’uso ideale<\/th> Debolezza<\/th><\/tr><\/thead> Synchronizer Token (STP)<\/td> Token unico per sessione salvato sul server, inserito in un campo nascosto o header<\/td> S\u00ec, richiede storage<\/td> App stateful con rendering server-side<\/td> Pi\u00f9 memoria e gestione dello stato<\/td><\/tr> Double Submit Cookie<\/td> Token in un cookie e replicato nel body o header; il server confronta i due valori<\/td> No<\/td> API stateless e SPA<\/td> Vulnerabile se il token non \u00e8 firmato<\/td><\/tr> Signed Double Submit<\/td> Come sopra ma il token \u00e8 firmato con HMAC e un segreto server<\/td> No<\/td> SPA e microservizi moderni<\/td> Resta sensibile all’XSS<\/td><\/tr> SameSite cookie<\/td> Il browser limita l’invio del cookie nelle richieste cross-site<\/td> No<\/td> Difesa di base per ogni app<\/td> Supporto e comportamento variabili sui browser legacy<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n csrf-csrf<\/code>. \u00c8 il compromesso migliore per le applicazioni Node.js moderne: non richiede storage di sessione dedicato, funziona per form tradizionali e SPA, e la firma HMAC impedisce a un attaccante di fabbricare un token valido anche conoscendo l’algoritmo. Lo abbineremo a SameSite<\/code>, alla validazione dell’header Origin<\/code> e a HTTPS per ottenere una difesa a strati, esattamente come raccomanda OWASP.<\/p>\n\n\n\nStep 1-2: Inizializzare il progetto Express 5<\/h2>\n\n\n\n
\"type\": \"module\"<\/code>) perch\u00e9 sono lo standard per i progetti Node.js nel 2026.<\/p>\n\n\n\nmkdir csrf-demo && cd csrf-demo\nnpm init -y\nnpm pkg set type=\"module\"\nnpm install express csrf-csrf cookie-parser helmet\nnpm install --save-dev nodemon<\/code><\/pre>\n\n\n\npackage.json<\/code> per ricaricare il server a ogni modifica durante lo sviluppo:<\/p>\n\n\n\n\/\/ package.json (estratto)\n\"scripts\": {\n \"dev\": \"nodemon app.js\",\n \"start\": \"node app.js\"\n}<\/code><\/pre>\n\n\n\napp.js<\/code> con uno scheletro Express 5 minimo. Express 5 introduce una gestione degli errori pi\u00f9 rigorosa e una migliore propagazione delle Promise rifiutate, quindi il codice asincrono \u00e8 pi\u00f9 sicuro per impostazione predefinita rispetto a Express 4.<\/p>\n\n\n\n\/\/ app.js\nimport express from \"express\";\nimport helmet from \"helmet\";\nimport cookieParser from \"cookie-parser\";\n\nconst app = express();\n\napp.use(helmet());\napp.use(express.json());\napp.use(express.urlencoded({ extended: false }));\n\nconst PORT = process.env.PORT || 3000;\napp.listen(PORT, () => {\n console.log(`Server in ascolto su http:\/\/localhost:${PORT}`);\n});<\/code><\/pre>\n\n\n\nnpm run dev<\/code>. Dovresti vedere il messaggio di ascolto sulla porta 3000. Questo \u00e8 il punto di partenza: un server che al momento non ha alcuna protezione CSRF. Nei prossimi step la aggiungiamo.<\/p>\n\n\n\nStep 3-4: Configurare cookie-parser e il segreto CSRF<\/h2>\n\n\n\n
cookie-parser<\/code> prima della protezione CSRF, perch\u00e9 il middleware CSRF legge il token dal cookie.<\/p>\n\n\n\n\/\/ app.js (aggiunte)\nimport crypto from \"node:crypto\";\n\n\/\/ cookie-parser con un segreto per i cookie firmati\nconst COOKIE_SECRET = process.env.COOKIE_SECRET ||\n crypto.randomBytes(32).toString(\"hex\");\napp.use(cookieParser(COOKIE_SECRET));<\/code><\/pre>\n\n\n\n# Genera un segreto CSRF robusto da terminale\nnode -e \"console.log(require('crypto').randomBytes(32).toString('hex'))\"\n# Esempio di output:\n# 9f2c1a7b4e8d0c63a5f1b9d72e4c8a0f6b3d51e9c7a2f48b1d6e0a93c5f7b284<\/code><\/pre>\n\n\n\n.env<\/code> (mai versionato in git) come CSRF_SECRET<\/code> e COOKIE_SECRET<\/code>. In produzione, usa il gestore di segreti del tuo provider (ad esempio le variabili d’ambiente del servizio o un vault dedicato). Un segreto debole o hardcoded \u00e8 uno degli errori pi\u00f9 comuni che vanifica l’intera protezione CSRF.<\/p>\n\n\n\nStep 5-6: Installare e configurare csrf-csrf<\/h2>\n\n\n\n
doubleCsrf<\/code> di csrf-csrf<\/code> restituisce un middleware e una funzione per generare il token. Configuriamola con un segreto HMAC, le opzioni del cookie e la logica di estrazione del token dalla richiesta.<\/p>\n\n\n\n\/\/ csrf.js\nimport { doubleCsrf } from \"csrf-csrf\";\n\nconst isProd = process.env.NODE_ENV === \"production\";\n\nexport const {\n doubleCsrfProtection, \/\/ middleware da applicare alle rotte\n generateCsrfToken, \/\/ genera e imposta il token\n invalidCsrfTokenError \/\/ errore tipizzato per la gestione\n} = doubleCsrf({\n getSecret: () => process.env.CSRF_SECRET,\n getSessionIdentifier: (req) => req.sessionID || req.ip,\n cookieName: isProd ? \"__Host-psifi.x-csrf-token\" : \"x-csrf-token\",\n cookieOptions: {\n httpOnly: true,\n sameSite: \"strict\",\n secure: isProd,\n path: \"\/\"\n },\n size: 32,\n ignoredMethods: [\"GET\", \"HEAD\", \"OPTIONS\"],\n getTokenFromRequest: (req) =>\n req.headers[\"x-csrf-token\"] || req.body?._csrf\n});<\/code><\/pre>\n\n\n\ngetSecret<\/code> fornisce il segreto HMAC con cui il token viene firmato e verificato. getSessionIdentifier<\/code> lega il token a un’identit\u00e0 (la sessione se presente, altrimenti l’IP) per evitare il riuso del token tra utenti diversi. ignoredMethods<\/code> esclude i metodi sicuri e idempotenti: GET, HEAD e OPTIONS non devono mai cambiare stato, quindi non richiedono un token CSRF.<\/p>\n\n\n\ncookieOptions<\/code> sono critiche. httpOnly: true<\/code> impedisce a JavaScript di leggere il cookie, riducendo l’impatto di un eventuale XSS. sameSite: \"strict\"<\/code> dice al browser di non inviare il cookie nelle richieste cross-site. secure: true<\/code> in produzione impone HTTPS. Il prefisso __Host-<\/code> sul nome del cookie in produzione aggiunge una garanzia extra: il browser accetta quel cookie solo se \u00e8 impostato con Secure<\/code>, path=\/<\/code> e senza dominio esplicito.<\/p>\n\n\n\ngetTokenFromRequest<\/code> definisce dove il server cerca il token nella richiesta in arrivo: prima nell’header x-csrf-token<\/code> (usato dalle SPA), poi nel campo nascosto _csrf<\/code> del body (usato dai form HTML tradizionali). Questo doppio supporto rende lo stesso backend compatibile sia con i form che con le SPA.<\/p>\n\n\n\nStep 7: Proteggere le rotte che cambiano stato<\/h2>\n\n\n\n
doubleCsrfProtection<\/code> alle rotte che modificano lo stato. Hai due opzioni: applicarlo globalmente (e poi escludere le rotte pubbliche) oppure applicarlo per rotta. L’approccio per rotta \u00e8 pi\u00f9 esplicito e meno soggetto a errori, quindi \u00e8 quello che useremo.<\/p>\n\n\n\n\/\/ app.js (aggiunte)\nimport { doubleCsrfProtection, generateCsrfToken } from \".\/csrf.js\";\n\n\/\/ Endpoint per ottenere il token (usato da form e SPA)\napp.get(\"\/csrf-token\", (req, res) => {\n const token = generateCsrfToken(req, res);\n res.json({ csrfToken: token });\n});\n\n\/\/ Rotta protetta: cambia stato, richiede un token valido\napp.post(\"\/account\/email\", doubleCsrfProtection, (req, res) => {\n const { nuovaEmail } = req.body;\n \/\/ ... logica di aggiornamento ...\n res.json({ ok: true, email: nuovaEmail });\n});<\/code><\/pre>\n\n\n\nGET \/csrf-token<\/code> genera il token, lo imposta nel cookie firmato e ne restituisce il valore al client. La rotta POST \/account\/email<\/code> \u00e8 protetta: se arriva senza un token valido, il middleware blocca la richiesta prima che raggiunga la tua logica. Ogni endpoint POST, PUT, PATCH o DELETE che modifica dati deve avere doubleCsrfProtection<\/code> nella sua catena di middleware.<\/p>\n\n\n\nGET \/account\/elimina<\/code> che cancella dati, non c’\u00e8 token CSRF che tenga, perch\u00e9 un semplice tag <img src=\"...\"><\/code> su una pagina ostile la attiverebbe. Sposta sempre le azioni distruttive su POST o DELETE.<\/p>\n\n\n\nStep 8: Servire il token a un form HTML<\/h2>\n\n\n\n
\/\/ app.js (aggiunte)\napp.get(\"\/profilo\", (req, res) => {\n const token = generateCsrfToken(req, res);\n res.send(`\n <!DOCTYPE html>\n <html lang=\"it\">\n <body>\n <h1>Cambia email<\/h1>\n <form action=\"\/account\/email\" method=\"POST\">\n <input type=\"hidden\" name=\"_csrf\" value=\"${token}\">\n <input type=\"email\" name=\"nuovaEmail\" required>\n <button type=\"submit\">Salva<\/button>\n <\/form>\n <\/body>\n <\/html>\n `);\n});<\/code><\/pre>\n\n\n\n_csrf<\/code>. Il middleware confronta i due e verifica la firma. Un sito malevolo pu\u00f2 forzare il browser a inviare il cookie, ma non conosce il valore del token da inserire nel body, e non pu\u00f2 leggerlo a causa della Same-Origin Policy. Per questo l’attacco fallisce.<\/p>\n\n\n\nReferer<\/code>, esponendo il token.<\/p>\n\n\n\nStep 9: Inviare il token da una SPA (fetch e Axios)<\/h2>\n\n\n\n
\/\/ client.js (frontend SPA)\n\/\/ 1. Recupera il token all'avvio dell'app\nasync function initCsrf() {\n const res = await fetch(\"\/csrf-token\", { credentials: \"include\" });\n const { csrfToken } = await res.json();\n return csrfToken;\n}\n\n\/\/ 2. Allega il token a ogni richiesta che cambia stato\nasync function aggiornaEmail(csrfToken, nuovaEmail) {\n const res = await fetch(\"\/account\/email\", {\n method: \"POST\",\n credentials: \"include\",\n headers: {\n \"Content-Type\": \"application\/json\",\n \"x-csrf-token\": csrfToken\n },\n body: JSON.stringify({ nuovaEmail })\n });\n return res.json();\n}<\/code><\/pre>\n\n\n\ncredentials: \"include\"<\/code> \u00e8 obbligatoria: senza di essa il browser non invia il cookie del token e la verifica fallisce sempre. Con Axios, puoi automatizzare l’allegato del token con un interceptor, cos\u00ec non devi ricordartene a ogni chiamata:<\/p>\n\n\n\n\/\/ Axios: interceptor globale\nimport axios from \"axios\";\n\nconst api = axios.create({ withCredentials: true });\nlet csrfToken = null;\n\nexport async function setupCsrf() {\n const { data } = await api.get(\"\/csrf-token\");\n csrfToken = data.csrfToken;\n}\n\napi.interceptors.request.use((config) => {\n if ([\"post\", \"put\", \"patch\", \"delete\"].includes(config.method)) {\n config.headers[\"x-csrf-token\"] = csrfToken;\n }\n return config;\n});\n\nexport default api;<\/code><\/pre>\n\n\n\nlocalStorage<\/code>. Il localStorage<\/code> \u00e8 leggibile da qualsiasi script nella pagina, quindi un XSS lo esporrebbe immediatamente. Se il token scade o una richiesta restituisce un errore CSRF, richiama setupCsrf()<\/code> per ottenerne uno nuovo.<\/p>\n\n\n\nStep 10: Difese a strati con SameSite, Origin e HTTPS<\/h2>\n\n\n\n
Cookie SameSite sulla sessione<\/h3>\n\n\n\n
SameSite=Strict<\/code> o Lax<\/code> su tutti i cookie di sessione, non solo sul token CSRF. Strict<\/code> blocca l’invio del cookie in qualsiasi richiesta cross-site. Lax<\/code> lo consente solo nelle navigazioni di primo livello (GET su un link), offrendo un buon equilibrio tra sicurezza ed esperienza utente. Non usare mai SameSite=None<\/code> senza Secure<\/code>.<\/p>\n\n\n\nValidazione dell’header Origin<\/h3>\n\n\n\n
Origin<\/code> (o in mancanza Referer<\/code>) contro una lista di domini fidati. Le richieste senza un Origin valido vengono respinte prima ancora di controllare il token.<\/p>\n\n\n\n\/\/ originGuard.js\nconst ORIGINI_FIDATE = new Set([\n \"https:\/\/app.tuodominio.it\",\n \"https:\/\/tuodominio.it\"\n]);\n\nexport function originGuard(req, res, next) {\n const metodiSicuri = [\"GET\", \"HEAD\", \"OPTIONS\"];\n if (metodiSicuri.includes(req.method)) return next();\n\n const origin = req.headers.origin ||\n (req.headers.referer && new URL(req.headers.referer).origin);\n\n if (!origin || !ORIGINI_FIDATE.has(origin)) {\n return res.status(403).json({ errore: \"Origin non valida\" });\n }\n next();\n}<\/code><\/pre>\n\n\n\noriginGuard<\/code> prima di doubleCsrfProtection<\/code> sulle rotte sensibili. Questo doppio controllo \u00e8 particolarmente efficace contro attacchi che riescono a superare uno solo dei due meccanismi.<\/p>\n\n\n\nHTTPS obbligatorio<\/h3>\n\n\n\n
secure<\/code> sui cookie e aggiungi l’header HSTS. Se non hai ancora un certificato, configurarne uno gratuito \u00e8 semplice e veloce.<\/p>\n\n\n\nStep 11: Gestire gli errori CSRF in modo pulito<\/h2>\n\n\n\n
csrf-csrf<\/code> lancia un errore tipizzato. Devi intercettarlo con un gestore di errori Express per restituire una risposta 403 chiara, invece di esporre uno stack trace. Registra il gestore dopo tutte le rotte.<\/p>\n\n\n\n\/\/ app.js (in fondo, dopo le rotte)\nimport { invalidCsrfTokenError } from \".\/csrf.js\";\n\napp.use((err, req, res, next) => {\n if (err === invalidCsrfTokenError || err.code === \"EBADCSRFTOKEN\") {\n return res.status(403).json({\n errore: \"Token CSRF mancante o non valido\",\n azione: \"Ricarica la pagina e riprova\"\n });\n }\n next(err);\n});<\/code><\/pre>\n\n\n\nStep 12: Testare la protezione CSRF<\/h2>\n\n\n\n
curl<\/code> per simulare le richieste.<\/p>\n\n\n\n# 1. Richiesta SENZA token: deve essere respinta con 403\ncurl -i -X POST http:\/\/localhost:3000\/account\/email \\\n -H \"Content-Type: application\/json\" \\\n -d '{\"nuovaEmail\":\"test@example.it\"}'\n# Atteso: HTTP\/1.1 403 Forbidden\n# {\"errore\":\"Token CSRF mancante o non valido\", ...}\n\n# 2. Ottieni un token e salva i cookie\ncurl -c cookies.txt http:\/\/localhost:3000\/csrf-token\n# Output: {\"csrfToken\":\"a1b2c3....\"}\n\n# 3. Richiesta CON token valido e cookie: deve passare\ncurl -i -X POST http:\/\/localhost:3000\/account\/email \\\n -b cookies.txt \\\n -H \"Content-Type: application\/json\" \\\n -H \"x-csrf-token: a1b2c3....\" \\\n -d '{\"nuovaEmail\":\"test@example.it\"}'\n# Atteso: HTTP\/1.1 200 OK\n# {\"ok\":true,\"email\":\"test@example.it\"}<\/code><\/pre>\n\n\n\nIl progetto completo funzionante<\/h2>\n\n\n\n
app.js<\/code> completo che mette insieme tutti gli step. Con i file csrf.js<\/code> e originGuard.js<\/code> mostrati sopra, questo \u00e8 un server Express 5 con protezione CSRF pronta per essere estesa.<\/p>\n\n\n\n\/\/ app.js (completo)\nimport express from \"express\";\nimport helmet from \"helmet\";\nimport cookieParser from \"cookie-parser\";\nimport crypto from \"node:crypto\";\nimport {\n doubleCsrfProtection,\n generateCsrfToken,\n invalidCsrfTokenError\n} from \".\/csrf.js\";\nimport { originGuard } from \".\/originGuard.js\";\n\nconst app = express();\nconst isProd = process.env.NODE_ENV === \"production\";\n\napp.use(helmet());\napp.use(express.json());\napp.use(express.urlencoded({ extended: false }));\n\nconst COOKIE_SECRET = process.env.COOKIE_SECRET ||\n crypto.randomBytes(32).toString(\"hex\");\napp.use(cookieParser(COOKIE_SECRET));\n\nif (isProd) app.set(\"trust proxy\", 1);\n\n\/\/ Endpoint token per SPA e form\napp.get(\"\/csrf-token\", (req, res) => {\n res.json({ csrfToken: generateCsrfToken(req, res) });\n});\n\n\/\/ Form server-side\napp.get(\"\/profilo\", (req, res) => {\n const token = generateCsrfToken(req, res);\n res.send(`<form action=\"\/account\/email\" method=\"POST\">\n <input type=\"hidden\" name=\"_csrf\" value=\"${token}\">\n <input type=\"email\" name=\"nuovaEmail\" required>\n <button>Salva<\/button><\/form>`);\n});\n\n\/\/ Rotta protetta con difesa a strati\napp.post(\"\/account\/email\", originGuard, doubleCsrfProtection,\n (req, res) => {\n res.json({ ok: true, email: req.body.nuovaEmail });\n });\n\n\/\/ Gestore errori CSRF\napp.use((err, req, res, next) => {\n if (err === invalidCsrfTokenError || err.code === \"EBADCSRFTOKEN\") {\n return res.status(403).json({ errore: \"Token CSRF non valido\" });\n }\n next(err);\n});\n\nconst PORT = process.env.PORT || 3000;\napp.listen(PORT, () => console.log(`In ascolto su :${PORT}`));<\/code><\/pre>\n\n\n\napp.js<\/code>, csrf.js<\/code>, originGuard.js<\/code>, un file .env<\/code> con i segreti e package.json<\/code>. Da qui puoi collegare un database, un sistema di sessioni con express-session<\/code> o un frontend SPA senza modificare la logica di protezione.<\/p>\n\n\n\n6 errori comuni nella protezione CSRF<\/h2>\n\n\n\n
SameSite<\/code> in modo corretto. Migra a csrf-csrf<\/code> o alla protezione nativa del tuo framework.<\/li>GET \/elimina<\/code> \u00e8 attivabile con un tag <img><\/code> e nessun token pu\u00f2 proteggerla. Usa POST, PUT, PATCH o DELETE.<\/li>Strict<\/code> o Lax<\/code>.<\/li><\/ol>\n\n\n\nRisoluzione dei problemi (troubleshooting)<\/h2>\n\n\n\n