XSS tramite innerHTML e come prevenirlo

Impostare el.innerHTML = userInput analizza la stringa come HTML. Se userInput contiene tag <script> o attributi di gestori di eventi (onclick, onerror), il browser li interpreta ed esegue il codice controllato dall'attaccante nella pagina.

Qualsiasi codice che inserisce dati utente nell'HTML, dai template lato server al rendering lato client, espone al rischio XSS se i dati non vengono sottoposti a escape. Le applicazioni a pagina singola che costruiscono innerHTML a partire dalle risposte delle API sono particolarmente esposte quando tali risposte includono contenuti degli utenti.

Un nome utente "Bob<img src=x onerror=alert(1)>" impostato tramite div.innerHTML = `Welcome, ${user}` esegue alert(1) quando l'immagine non riesce a caricarsi. Lo stesso payload come testo semplice, tramite textContent, è innocuo: il browser vede solo caratteri, non tag.

textContent imposta solo testo: i caratteri speciali HTML vengono visualizzati come caratteri letterali, mai come tag. Questo è lo strumento corretto nel 90% dei casi. Utilizzi innerHTML solo quando deve effettivamente visualizzare markup, non semplice testo.

Per creare elementi contenenti dati utente, li costruisca con createElement e textContent: const li = document.createElement("li"); li.textContent = name; ul.appendChild(li);. Il risultato è strutturalmente identico a innerHTML, ma sicuro contro XSS per costruzione.

Per HTML attendibile generato dal server, ad esempio l'output dei propri template o rich text sanificato proveniente da un editor attendibile, innerHTML va bene. Non lo applichi mai direttamente a dati provenienti da fonti non attendibili senza prima sanificarli.

Se gli utenti inviano rich text, ad esempio tramite un editor di commenti o il rendering di Markdown, lo sanifichi prima di impostare innerHTML: el.innerHTML = DOMPurify.sanitize(richHtml). DOMPurify rimuove tag e attributi pericolosi mantenendo formattazioni sicure come <b>, <em> e <a>.

el.insertAdjacentHTML("beforeend", html) analizza le stringhe HTML, creando la stessa superficie d'attacco XSS di innerHTML. Si applicano le stesse regole: non inserisca mai direttamente dati utente; li sanifichi oppure utilizzi i metodi DOM. Lo stesso vale per document.write, anche se ormai nessuno dovrebbe più utilizzarlo.

React, Vue, Svelte e Angular sottopongono a escape il testo interpolato per impostazione predefinita: {name} è sicuro. Espongono però vie per aggirare questa protezione, come dangerouslySetInnerHTML in React e v-html in Vue, che comportano lo stesso rischio XSS; le utilizzi con parsimonia e insieme alla sanificazione.

Anche i valori degli attributi possono essere vettori d'attacco: <a href={url}> con url="javascript:alert(1)" esegue il codice al clic. Convalidi gli URL schema per schema, consentendo solo http:, https:, mailto: e tel:, prima di inserire dati utente in href, src o altri attributi che contengono URL.

I browser moderni supportano Trusted Types: configuri CSP con require-trusted-types-for 'script' e innerHTML rifiuterà le stringhe grezze, accettando solo valori elaborati tramite una policy. In questo modo XSS diventa impossibile grazie all'API, anziché dipendere dalla disciplina degli sviluppatori.

Nessun singolo livello è sufficiente. Combini: validazione dell'input sul server, escaping dell'output durante il rendering, CSP per bloccare gli script iniettati, Trusted Types per rifiutare le stringhe grezze e una revisione della sicurezza per qualsiasi uso di innerHTML. Una difesa stratificata resiste a un bug presente in uno qualsiasi dei livelli.

Perché el.textContent = userInput è sicuro contro XSS, mentre el.innerHTML = userInput è pericoloso?

Usare innerHTML con dati forniti dall'utente è il classico vettore XSS. Usi textContent per il testo e createElement+textContent per la struttura; ricorra a DOMPurify quando è necessario HTML avanzato. Validi gli schemi URL per i valori degli attributi. Combini CSP e Trusted Types per neutralizzare i bug che sfuggono alla revisione del codice. I framework moderni eseguono l'escaping per impostazione predefinita: mantenga rari e sottoposti a revisione i relativi punti di uscita non sicuri.