{"id":245,"date":"2026-06-19T08:00:00","date_gmt":"2026-06-19T08:00:00","guid":{"rendered":"https:\/\/shattered.io\/it\/2026\/06\/19\/xss-prevention-nodejs\/"},"modified":"2026-06-19T17:02:13","modified_gmt":"2026-06-19T17:02:13","slug":"xss-prevention-nodejs","status":"publish","type":"post","link":"https:\/\/shattered.io\/it\/2026\/06\/19\/xss-prevention-nodejs\/","title":{"rendered":"XSS in Node.js: Prevenirlo in 12 Step [2026]"},"content":{"rendered":"\n

Il Cross-Site Scripting (XSS)<\/strong> \u00e8 la vulnerabilit\u00e0 web pi\u00f9 segnalata nel 2025 secondo OWASP, presente nel 68% delle applicazioni testate. Con Node.js e Express.js, un singolo campo di input non protetto \u00e8 sufficiente affinch\u00e9 un aggressore inietti codice JavaScript malevolo, rubi i cookie di sessione degli utenti, esegua azioni per conto loro o installi malware. Questa guida ti mostra come prevenire l’XSS in Node.js in 12 step pratici, con codice funzionante, i pacchetti npm giusti e una checklist completa per la produzione.<\/p>\n\n\n\n

Cosa Sono gli Attacchi XSS e Perch\u00e9 Node.js \u00e8 a Rischio<\/h2>\n\n\n\n

Un attacco Cross-Site Scripting (XSS)<\/strong> si verifica quando un aggressore riesce a iniettare codice JavaScript in una pagina web visualizzata da altri utenti. Il browser della vittima esegue quel codice perch\u00e9 lo percepisce come parte legittima della pagina. Il danno pu\u00f2 variare dal furto di cookie di sessione (e quindi dell’accesso all’account) alla reindirizzazione su siti di phishing, all’esecuzione di keylogger nel browser.<\/p>\n\n\n\n

Node.js e Express.js non sono intrinsecamente pi\u00f9 vulnerabili di altri framework, ma la natura dinamica di JavaScript, la facilit\u00e0 con cui si concatenano stringhe HTML e la mancanza di un sistema di template sicuro di default espongono molti sviluppatori a rischi evitabili. Un tipico errore \u00e8 restituire direttamente all’utente dati non sanitizzati prelevati dal database o dai parametri della richiesta HTTP.<\/p>\n\n\n\n

Esistono tre categorie principali di XSS, ciascuna con caratteristiche e vettori di attacco distinti. Comprenderle \u00e8 il primo passo verso una protezione efficace.<\/p>\n\n\n\n

Tipo di XSS<\/th>Come Funziona<\/th>Persistenza<\/th>Esempio<\/th><\/tr><\/thead>
Stored XSS<\/strong><\/td>Il payload viene salvato nel database e servito a tutti gli utenti<\/td>Permanente<\/td>Commento con <script> in un forum<\/td><\/tr>
Reflected XSS<\/strong><\/td>Il payload viene incluso nella richiesta e rimbalzato nella risposta<\/td>Temporanea<\/td>Parametro URL con codice malevolo<\/td><\/tr>
DOM-Based XSS<\/strong><\/td>Il payload modifica il DOM lato client tramite JavaScript<\/td>Variabile<\/td>document.write(location.hash)<\/td><\/tr>
Blind XSS<\/strong><\/td>Il payload viene eseguito in aree non visibili all’aggressore<\/td>Permanente<\/td>Campo di log visualizzato dall’amministratore<\/td><\/tr>
mXSS (Mutation XSS)<\/strong><\/td>Il browser muta il markup sanitizzato in codice eseguibile<\/td>Variabile<\/td>Parsing anomalo di tag annidati<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Prerequisiti per Seguire il Tutorial<\/h2>\n\n\n\n

Prima di iniziare, assicurati di avere installato nel tuo ambiente di sviluppo:<\/p>\n\n\n\n

  • Node.js 20.x LTS<\/strong> o superiore (verificare con node --version<\/code>)<\/li>
  • npm 10.x<\/strong> o superiore (verificare con npm --version<\/code>)<\/li>
  • Express.js 4.x<\/strong> installato nel progetto<\/li>
  • Un editor di testo come VS Code con il plugin ESLint configurato<\/li>
  • Conoscenza base di JavaScript e del protocollo HTTP<\/li>
  • Terminale con accesso a riga di comando<\/li><\/ul>\n\n\n\n

    Il tutorial usa Node.js 20 LTS perch\u00e9 \u00e8 la versione supportata a lungo termine attiva nel 2026 e include moduli di sicurezza maturi. Puoi seguire le stesse istruzioni su Node.js 22.x senza modifiche sostanziali al codice.<\/p>\n\n\n\n

    Step 1: Creare il Progetto e Riprodurre la Vulnerabilit\u00e0 XSS<\/h2>\n\n\n\n

    Prima di implementare la protezione, \u00e8 utile vedere concretamente come si manifesta una vulnerabilit\u00e0 XSS. Creiamo un’applicazione Express.js volutamente vulnerabile per capire il problema dal vivo.<\/p>\n\n\n\n

    mkdir xss-demo && cd xss-demo\nnpm init -y\nnpm install express ejs\n\n# Struttura del progetto\nxss-demo\/\n\u251c\u2500\u2500 server.js\n\u251c\u2500\u2500 views\/\n\u2502   \u2514\u2500\u2500 index.ejs\n\u2514\u2500\u2500 package.json<\/code><\/pre>\n\n\n\n
    Crea un file server.js<\/code> con un semplice endpoint vulnerabile per vedere l’attacco in azione:<\/p>\n\n\n\n
    \/\/ server.js - VERSIONE VULNERABILE (solo per dimostrazione, non usare in produzione)\nconst express = require('express');\nconst app = express();\n\napp.use(express.urlencoded({ extended: true }));\napp.use(express.json());\n\n\/\/ VULNERABILE: riflette il parametro \"q\" senza sanitizzazione alcuna\napp.get('\/search', (req, res) => {\n  const query = req.query.q || '';\n  \/\/ MAI fare cos\u00ec: concatenare HTML con input utente non sanitizzato\n  res.send(`<h1>Risultati per: ${query}<\/h1>`);\n});\n\n\/\/ VULNERABILE: salva e restituisce commenti HTML senza sanitizzazione\nconst comments = [];\napp.post('\/comment', (req, res) => {\n  comments.push(req.body.text); \/\/ salva HTML grezzo\n  res.json({ ok: true });\n});\n\napp.get('\/comments', (req, res) => {\n  \/\/ MAI fare cos\u00ec: renderizzare HTML grezzo dall'utente\n  res.send(comments.map(c => `<p>${c}<\/p>`).join(''));\n});\n\napp.listen(3000, () => console.log('Server vulnerabile attivo sulla porta 3000'));\n<\/code><\/pre>\n\n\n\n
    Se avvii questo server e visiti http:\/\/localhost:3000\/search?q=<script>alert('XSS')<\/script><\/code>, vedrai un popup di alert nel browser. Questo dimostra che il codice JavaScript iniettato viene eseguito nel contesto della tua applicazione. Nei passi seguenti correggeremo ogni singola vulnerabilit\u00e0 con strumenti professionali.<\/p>\n\n\n\n
    Step 2: Installare le Dipendenze di Sicurezza per la Prevenzione XSS<\/h2>\n\n\n\n
    L’ecosistema npm offre diversi pacchetti specifici per prevenire l’XSS in Node.js. Ogni pacchetto ha un ruolo preciso e vanno usati in combinazione per una protezione a livelli.<\/p>\n\n\n\n
    # Installa le dipendenze di sicurezza principali\nnpm install helmet sanitize-html express-validator xss express-session\n\n# Dipendenze di sviluppo per l'analisi statica del codice\nnpm install --save-dev eslint eslint-plugin-security nodemon\n\n# Verifica le vulnerabilit\u00e0 note nelle dipendenze\nnpm audit --audit-level=moderate<\/code><\/pre>\n\n\n\n
    Pacchetto npm<\/th>Funzione<\/th>Quando Usarlo<\/th><\/tr><\/thead>
    helmet<\/strong><\/td>Imposta le HTTP security headers inclusa la CSP<\/td>Sempre, in ogni app Express.js<\/td><\/tr>
    sanitize-html<\/strong><\/td>Sanitizza HTML consentendo solo tag sicuri configurabili<\/td>Quando si accettano input HTML ricchi (blog, commenti)<\/td><\/tr>
    express-validator<\/strong><\/td>Valida e sanitizza i campi della richiesta HTTP<\/td>Validazione di form, API e parametri URL<\/td><\/tr>
    xss<\/strong><\/td>Filtro XSS basato su whitelist per HTML<\/td>Alternativa leggera a sanitize-html<\/td><\/tr>
    express-session<\/strong><\/td>Gestione sessioni con cookie sicuri<\/td>Applicazioni con autenticazione utente<\/td><\/tr>
    eslint-plugin-security<\/strong><\/td>Rileva pattern di codice vulnerabili a XSS durante lo sviluppo<\/td>In ogni progetto come controllo statico<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
    Esegui npm audit<\/code> come parte della pipeline CI\/CD per rilevare vulnerabilit\u00e0 note prima del deploy. GitHub Dependabot e Snyk possono automatizzare questo controllo su ogni pull request, avvisandoti quando viene pubblicata una patch di sicurezza per le dipendenze del progetto.<\/p>\n\n\n\n
    Step 3: Configurare Helmet.js con la Content Security Policy<\/h2>\n\n\n\n
    Helmet.js<\/strong> \u00e8 il middleware Express pi\u00f9 importante per la sicurezza delle intestazioni HTTP. Con una singola invocazione, imposta oltre 11 header che istruiscono il browser su come gestire le risorse della pagina, riducendo drasticamente la superficie d’attacco per XSS e altri attacchi lato client.<\/p>\n\n\n\n
    La Content Security Policy (CSP)<\/strong> \u00e8 lo strumento pi\u00f9 efficace contro l’XSS a livello di browser: definisce esplicitamente quali fonti di script, stili e altri contenuti sono autorizzate. Anche se un aggressore riesce ad iniettare un tag <script><\/code>, il browser lo blocca se la fonte non \u00e8 nella whitelist CSP. La CSP riduce l’impatto di XSS anche quando la sanitizzazione fallisce.<\/p>\n\n\n\n
    \/\/ server.js - Configurazione Helmet con CSP basata su nonce\nconst express = require('express');\nconst helmet = require('helmet');\nconst crypto = require('crypto');\n\nconst app = express();\n\n\/\/ Genera un nonce crittograficamente sicuro per ogni richiesta HTTP\napp.use((req, res, next) => {\n  res.locals.nonce = crypto.randomBytes(16).toString('base64');\n  next();\n});\n\n\/\/ Configurazione Helmet con CSP dinamica basata su nonce\napp.use((req, res, next) => {\n  helmet({\n    contentSecurityPolicy: {\n      directives: {\n        defaultSrc: [\"'self'\"],\n        scriptSrc: [\n          \"'self'\",\n          \/\/ Consenti solo script con il nonce corretto per questa richiesta\n          (req, res) => `'nonce-${res.locals.nonce}'`,\n        ],\n        styleSrc:    [\"'self'\", \"'unsafe-inline'\"],\n        imgSrc:      [\"'self'\", \"data:\", \"https:\"],\n        connectSrc:  [\"'self'\"],\n        fontSrc:     [\"'self'\"],\n        objectSrc:   [\"'none'\"],     \/\/ blocca plugin Flash e oggetti incorporati\n        frameSrc:    [\"'none'\"],     \/\/ blocca iframe non autorizzati (anti-clickjacking)\n        baseUri:     [\"'self'\"],     \/\/ impedisce injection del tag <base>\n        formAction:  [\"'self'\"],     \/\/ limita le destinazioni dei form\n        upgradeInsecureRequests: [], \/\/ forza HTTPS per le risorse HTTP\n      },\n      reportOnly: false,\n    },\n    xXssProtection: false, \/\/ disabilita l'header obsoleto X-XSS-Protection\n    crossOriginEmbedderPolicy: false,\n  })(req, res, next);\n});\n\napp.use(express.json({ limit: '10kb' }));\napp.use(express.urlencoded({ extended: false, limit: '10kb' }));\n\napp.listen(3000, () => console.log('Server con Helmet attivo sulla porta 3000'));\n<\/code><\/pre>\n\n\n\n
    Una nota importante: xXssProtection: false<\/code> non \u00e8 un errore di configurazione. L’header X-XSS-Protection<\/code> \u00e8 stato rimosso da Chrome, Firefox e Edge perch\u00e9 creava nuovi vettori di attacco invece di prevenirli. La documentazione ufficiale di Helmet consiglia esplicitamente di disabilitarlo. La protezione moderna si basa esclusivamente su CSP.<\/p>\n\n\n\n
    Step 4: Validare l’Input con express-validator<\/h2>\n\n\n\n
    La validazione dell’input<\/strong> \u00e8 la prima linea di difesa: rifiuta i dati che non corrispondono al formato atteso prima ancora che raggiungano la logica dell’applicazione. express-validator<\/code> \u00e8 la libreria standard per Express e si integra perfettamente con i middleware di route.<\/p>\n\n\n\n
    Il principio fondamentale \u00e8 chiaro: non esiste un “input sicuro” di default. Ogni dato proveniente dall’esterno, inclusi parametri URL, header HTTP, cookie e body della richiesta, va trattato come potenzialmente malevolo. Questo vale anche per i dati provenienti da API di terze parti o dal proprio database.<\/p>\n\n\n\n
    const { body, query, param, validationResult } = require('express-validator');\n\n\/\/ Middleware centralizzato per gestire gli errori di validazione\nconst handleValidation = (req, res, next) => {\n  const errors = validationResult(req);\n  if (!errors.isEmpty()) {\n    return res.status(400).json({\n      errors: errors.array().map(e => ({\n        field: e.path,\n        message: e.msg\n      }))\n    });\n  }\n  next();\n};\n\n\/\/ Route con validazione completa per un commento utente\napp.post('\/comment',\n  [\n    body('text')\n      .trim()                              \/\/ rimuovi spazi iniziali e finali\n      .notEmpty().withMessage('Il testo \u00e8 obbligatorio')\n      .isLength({ min: 1, max: 500 }).withMessage('Massimo 500 caratteri')\n      .escape(),                           \/\/ converte <, >, &, \", ' in entit\u00e0 HTML\n\n    body('author')\n      .trim()\n      .notEmpty().withMessage('Il nome \u00e8 obbligatorio')\n      .isAlphanumeric('it-IT', { ignore: ' -' })\n      .withMessage('Solo lettere, numeri, spazi e trattini')\n      .isLength({ min: 2, max: 50 }),\n\n    body('website')\n      .optional()\n      .isURL({ protocols: ['https'], require_tld: true })\n      .withMessage('Solo URL HTTPS validi'), \/\/ blocca javascript: e vbscript:\n  ],\n  handleValidation,\n  (req, res) => {\n    const { text, author } = req.body;\n    \/\/ text \u00e8 gi\u00e0 escapato grazie a .escape()\n    res.json({ ok: true, comment: { text, author } });\n  }\n);\n\n\/\/ Route con validazione del parametro URL numerico\napp.get('\/user\/:id',\n  [\n    param('id')\n      .isInt({ min: 1 }).withMessage('ID non valido')\n      .toInt(),                            \/\/ converte in numero intero sicuro\n  ],\n  handleValidation,\n  (req, res) => {\n    const userId = req.params.id; \/\/ \u00e8 gi\u00e0 un intero, non una stringa\n    res.json({ userId });\n  }\n);\n\n\/\/ Validazione parametri di ricerca con sanitizzazione personalizzata\napp.get('\/search',\n  [\n    query('q')\n      .trim()\n      .isLength({ max: 200 }).withMessage('Ricerca troppo lunga')\n      .customSanitizer(value => value.replace(\/[<>\"'`]\/g, '')),\n  ],\n  handleValidation,\n  (req, res) => {\n    res.json({ results: [], query: req.query.q });\n  }\n);\n<\/code><\/pre>\n\n\n\n
    Il metodo .escape()<\/code> di express-validator converte i caratteri speciali HTML in entit\u00e0 sicure: <<\/code> diventa &lt;<\/code>, ><\/code> diventa &gt;<\/code>, &<\/code> diventa &amp;<\/code>. Questo approccio \u00e8 ideale per i campi di testo puro. Se invece devi accettare HTML formattato (grassetto, liste, link), usa sanitize-html<\/code> come mostrato nel passo successivo.<\/p>\n\n\n\n
    Step 5: Sanitizzare l’HTML con sanitize-html<\/h2>\n\n\n\n
    Alcune applicazioni, come blog o editor di contenuti, devono accettare HTML dagli utenti. In questi casi l’escaping totale non \u00e8 praticabile: rimuoverebbe tutti i tag legittimi come <b><\/code>, <i><\/code> o <a><\/code>. La soluzione \u00e8 la sanitizzazione<\/strong>: mantieni solo i tag e gli attributi dalla whitelist, rimuovi tutto il resto incluso qualsiasi JavaScript.<\/p>\n\n\n\n
    const sanitizeHtml = require('sanitize-html');\n\n\/\/ Whitelist permissiva per editor di testo ricco (articoli del blog)\nconst RICH_TEXT_OPTIONS = {\n  allowedTags: [\n    'b', 'i', 'em', 'strong', 'u', 's',\n    'p', 'br', 'ul', 'ol', 'li',\n    'h1', 'h2', 'h3', 'blockquote',\n    'a', 'code', 'pre'\n  ],\n  allowedAttributes: {\n    'a': ['href', 'title', 'rel'],\n    'code': ['class'],\n    'pre': ['class']\n  },\n  allowedSchemes: ['https', 'mailto'],  \/\/ blocca javascript: e vbscript:\n  allowedSchemesByTag: {\n    'a': ['https', 'mailto']\n  },\n  disallowedTagsMode: 'discard',\n  enforceHtmlBoundary: true,\n  transformTags: {\n    'a': (tagName, attribs) => ({\n      tagName: 'a',\n      attribs: {\n        href: attribs.href || '#',\n        title: attribs.title || '',\n        rel: 'noopener noreferrer nofollow',\n        target: '_blank'\n      }\n    })\n  }\n};\n\n\/\/ Whitelist restrittiva per commenti degli utenti\nconst COMMENT_OPTIONS = {\n  allowedTags: ['b', 'i', 'em', 'strong', 'p', 'br'],\n  allowedAttributes: {},\n  allowedSchemes: [],\n};\n\n\/\/ Route che accetta HTML ricco per articoli\napp.post('\/article',\n  body('content').trim().notEmpty().isLength({ max: 50000 }),\n  handleValidation,\n  (req, res) => {\n    const rawHtml = req.body.content;\n\n    \/\/ Sanitizza prima di salvare nel database\n    const cleanHtml = sanitizeHtml(rawHtml, RICH_TEXT_OPTIONS);\n\n    \/\/ Controlla che la sanitizzazione non abbia prodotto contenuto vuoto\n    if (cleanHtml.trim().length === 0 && rawHtml.trim().length > 0) {\n      return res.status(400).json({ error: 'Contenuto non valido o interamente rimosso dalla sanitizzazione' });\n    }\n\n    res.json({ ok: true, bytesSaved: cleanHtml.length });\n  }\n);\n\n\/\/ Route per commenti con sanitizzazione minimale\napp.post('\/comment-html',\n  body('text').trim().notEmpty().isLength({ max: 500 }),\n  handleValidation,\n  (req, res) => {\n    const clean = sanitizeHtml(req.body.text, COMMENT_OPTIONS);\n    res.json({ ok: true, text: clean });\n  }\n);\n<\/code><\/pre>\n\n\n\n
    Un aspetto critico spesso trascurato: la sanitizzazione va applicata sia al momento della scrittura nel database che al momento della lettura. Sanitizzare solo all’uscita significa che dati corrotti nel database (magari inseriti prima di implementare la protezione) vengono comunque serviti all’utente. La best practice \u00e8 sanitizzare in entrata e applicare output encoding in uscita.<\/p>\n\n\n\n
    Step 6: Implementare l’Output Encoding Contestuale<\/h2>\n\n\n\n
    L’output encoding<\/strong> \u00e8 diverso dalla sanitizzazione: non rimuove i dati potenzialmente pericolosi, li trasforma in una rappresentazione sicura per il contesto specifico in cui vengono visualizzati. Il contesto \u00e8 fondamentale: il carattere <<\/code> in HTML richiede &lt;<\/code>, ma in un attributo JavaScript o in un URL richiede un encoding completamente diverso.<\/p>\n\n\n\n
    \/\/ Funzione di escaping HTML manuale (utile senza dipendenze esterne)\nfunction escapeHtml(text) {\n  if (typeof text !== 'string') return '';\n  return text\n    .replace(\/&\/g, '&amp;')     \/\/ deve essere PRIMA degli altri replace\n    .replace(\/<\/g, '&lt;')\n    .replace(\/>\/g, '&gt;')\n    .replace(\/\"\/g, '&quot;')\n    .replace(\/'\/g, '&#x27;')\n    .replace(\/\\\/\/g, '&/');    \/\/ protezione aggiuntiva per contesti inline\n}\n\n\/\/ Escaping sicuro per incorporare dati JSON in HTML\n\/\/ (es. passare dati dal server al client via <script>)\nfunction safeJsonEmbed(data) {\n  return JSON.stringify(data)\n    .replace(\/<\/g, '\\\\u003c')      \/\/ < potrebbe chiudere tag <script>\n    .replace(\/>\/g, '\\\\u003e')\n    .replace(\/&\/g, '\\\\u0026')\n    .replace(\/'\/g, '\\\\u0027');\n}\n\n\/\/ Validazione degli URL per evitare \"javascript:\" e \"vbscript:\"\nfunction sanitizeUrl(url) {\n  if (!url) return '#';\n  try {\n    const parsed = new URL(url);\n    if (!['https:', 'http:', 'mailto:'].includes(parsed.protocol)) {\n      return '#'; \/\/ protocollo pericoloso\n    }\n    return parsed.href;\n  } catch {\n    return '#'; \/\/ URL non valido\n  }\n}\n\n\/\/ Esempio di route sicura con EJS\n\/\/ EJS: <%= variabile %> applica escaping HTML automatico\n\/\/ EJS: <%- variabile %> restituisce HTML grezzo (usare SOLO con contenuto gi\u00e0 sanitizzato)\napp.get('\/profile\/:username', (req, res) => {\n  const user = {\n    name: req.params.username,\n    bio: '<script>alert(\"XSS\")<\/script> Sviluppatore',\n    website: 'javascript:alert(1)',\n    jsonData: { role: 'user', count: 42 }\n  };\n\n  res.render('profile', {\n    name: user.name,                     \/\/ EJS escaper\u00e0 con <%= name %>\n    bio: escapeHtml(user.bio),           \/\/ doppio escaping per sicurezza\n    website: sanitizeUrl(user.website),  \/\/ '#' per URL pericolosi\n    \/\/ Per JSON inline in script tag:\n    jsonEmbed: safeJsonEmbed(user.jsonData)\n    \/\/ Usare nel template: <script nonce=\"<%= nonce %>\">var d=<%-jsonEmbed%><\/script>\n  });\n});\n\n\/\/ Sempre usa res.json() per le API REST: imposta Content-Type: application\/json\n\/\/ e serializza correttamente, prevenendo injection di HTML nella risposta\napp.get('\/api\/profile', (req, res) => {\n  res.json({ name: 'Mario', role: 'admin' });\n});\n<\/code><\/pre>\n\n\n\n