Un XSS, o Cross-Site Scripting, è una vulnerabilità che permette a contenuto controllato da un attaccante di essere interpretato dal browser come parte di una pagina web considerata affidabile. Il punto critico non è semplicemente la presenza di JavaScript: il problema nasce quando dati non attendibili raggiungono l’output della pagina, il DOM o un altro contesto eseguibile senza essere gestiti correttamente.
Per chi utilizza WordPress, gli attacchi XSS meritano particolare attenzione perché la superficie non comprende soltanto il core del CMS, ma anche plugin, temi, form, shortcode, blocchi personalizzati, integrazioni esterne e codice sviluppato su misura.
La buona notizia è che la prevenzione non dipende da un singolo plugin o da un’intestazione HTTP. Le difese realmente efficaci partono da validazione, sanitizzazione ed escaping corretti, a cui possono essere aggiunti strumenti come Content Security Policy e Web Application Firewall come ulteriori livelli di protezione.
Cos’è un attacco XSS e come funziona il Cross-Site Scripting
Un attacco XSS si verifica quando un’applicazione permette a dati controllabili da un utente o da un’altra fonte non affidabile di raggiungere una pagina web in un contesto nel quale il browser può interpretarli come codice.
In termini semplici, il percorso può essere questo:
input non attendibile → gestione insufficiente → output o DOM → interpretazione da parte del browser
L’attaccante non deve necessariamente compromettere direttamente il server. Può essere sufficiente che l’applicazione generi una pagina nella quale un valore non sicuro viene inserito nel contesto sbagliato.
La documentazione OWASP dedicata alla prevenzione del Cross-Site Scripting insiste proprio sulla necessità di utilizzare difese adatte al contesto: output encoding, sanitizzazione HTML e protezioni offerte dai framework sono più importanti di filtri generici applicati alla fine.
Da input non affidabile a codice eseguito nel browser
Immagina un’applicazione che riceva un valore da:
- un parametro nell’URL;
- un campo di ricerca;
- un commento;
- un form;
- un profilo utente;
- un’API esterna;
- un valore salvato precedentemente nel database.
Il semplice fatto che il dato sia memorizzato nel database non lo rende sicuro.
Se viene successivamente inserito nell’HTML, in un attributo, in JavaScript o nel DOM senza la protezione richiesta da quel contesto, può diventare il punto di partenza di una vulnerabilità XSS.
È anche il motivo per cui la documentazione di sicurezza di WordPress raccomanda di non fidarsi automaticamente dei dati provenienti dal database, dagli utenti o da servizi di terze parti.
Cosa può ottenere un attaccante con una vulnerabilità XSS
L’impatto non è uguale in ogni applicazione.
Un XSS può permettere, a seconda del contesto e dei privilegi della vittima, di:
- eseguire azioni disponibili all’utente autenticato;
- leggere informazioni accessibili dalla pagina;
- modificare il contenuto mostrato nel browser;
- presentare form o interfacce ingannevoli;
- reindirizzare l’utente;
- interferire con la sessione;
- utilizzare il sito affidabile come punto di partenza per ulteriori azioni malevole.
Una vulnerabilità che colpisce un visitatore anonimo su una pagina completamente pubblica può avere conseguenze molto diverse da una vulnerabilità attivata nel browser di un amministratore WordPress.
Questo è un dettaglio importante: la gravità reale di un XSS dipende anche da chi esegue involontariamente il codice e da ciò che quell’utente può fare nell’applicazione.
Reflected, Stored e DOM-based XSS: le tre tipologie principali
La classificazione più utile distingue tre famiglie principali: Reflected XSS, Stored XSS e DOM-based XSS.
Capire la differenza aiuta sia a diagnosticare la vulnerabilità sia a scegliere la difesa corretta.
| Tipo di XSS | Dove nasce il dato malevolo | Persistenza | Dove si manifesta il problema |
|---|---|---|---|
| Reflected XSS | Richiesta HTTP corrente | Generalmente non persistente | Risposta generata dal server |
| Stored XSS | Dato precedentemente memorizzato | Persistente | Risposte successive che mostrano il dato |
| DOM-based XSS | Fonte elaborata da JavaScript nel browser | Dipende dalla fonte | Codice client-side e DOM |
Reflected XSS
Nel Reflected XSS il dato controllato dall’attaccante arriva normalmente attraverso la richiesta HTTP e viene inserito immediatamente nella risposta dell’applicazione senza una gestione adeguata.
Può accadere, ad esempio, quando una pagina ripete nell’HTML una query di ricerca, un messaggio di errore o un parametro ricevuto dall’URL.
Il payload non deve quindi essere necessariamente salvato nel sito: viene “riflesso” nella risposta.
Perché l’attacco funzioni, la vittima deve normalmente essere indotta ad aprire una richiesta preparata appositamente o raggiungerla attraverso un altro meccanismo controllato dall’attaccante.
Stored XSS
Lo Stored XSS, chiamato anche persistent XSS, segue un percorso diverso.
Il dato non sicuro viene prima memorizzato dall’applicazione e successivamente mostrato ad altri utenti.
Possibili punti di memorizzazione possono essere:
- commenti;
- profili;
- campi personalizzati;
- messaggi;
- ordini;
- impostazioni;
- contenuti importati da servizi esterni.
La distinzione importante è questa: il payload può essere conservato lato server o nel database, ma l’XSS viene normalmente eseguito nel browser dell’utente quando il dato vulnerabile viene renderizzato.
Questa dinamica può rendere uno Stored XSS particolarmente insidioso, perché più utenti possono raggiungere il contenuto senza dover aprire ogni volta uno specifico URL preparato dall’attaccante.
DOM-based XSS
Nel DOM-based XSS il problema si trova invece nel codice JavaScript eseguito nel browser.
Uno script può prendere dati da una fonte controllabile e inserirli in un elemento o in una funzione capace di interpretarli in modo pericoloso.
Il problema può nascere, per esempio, quando codice client-side utilizza sorgenti non attendibili e le passa direttamente a sink come innerHTML senza una gestione adeguata.
In questo caso una protezione applicata esclusivamente sul traffico server-side può non essere sufficiente, perché la trasformazione vulnerabile avviene direttamente nel browser.
Per un approfondimento tecnico sulle tre classi, la Web Security Academy di PortSwigger mantiene una documentazione dettagliata su Reflected, Stored e DOM-based XSS.
Perché gli attacchi XSS possono essere pericolosi
Il modo più corretto di valutare un XSS è evitare due estremi: considerarlo sempre un problema minore oppure descriverlo automaticamente come una compromissione completa del server.
Entrambe le semplificazioni possono essere sbagliate.
Sessioni, account e dati accessibili all’utente
Il codice eseguito attraverso un XSS opera normalmente nel contesto della pagina vulnerabile e può interagire con ciò che il browser rende disponibile a quella pagina.
A seconda delle protezioni implementate, può quindi tentare di:
- leggere informazioni presenti nell’interfaccia;
- effettuare richieste con i privilegi della vittima;
- modificare il contenuto della pagina;
- sfruttare funzionalità a cui l’utente ha già accesso.
Attributi dei cookie come HttpOnly possono limitare alcune tecniche di sottrazione diretta dei cookie, ma non correggono la vulnerabilità XSS e non impediscono necessariamente al codice malevolo di compiere azioni attraverso la sessione già autenticata.
Modifica delle pagine, phishing e azioni eseguite come vittima
Un XSS può anche modificare ciò che l’utente vede.
Questo apre scenari che vanno dal semplice defacement della pagina alla visualizzazione di:
- falsi moduli di autenticazione;
- messaggi ingannevoli;
- pulsanti modificati;
- contenuti provenienti da fonti controllate dall’attaccante.
Se la vittima dispone di privilegi elevati, le conseguenze possono aumentare in modo significativo.
Su WordPress, ad esempio, un XSS che raggiunge esclusivamente un utente con capacità limitate non ha lo stesso profilo di rischio di uno che può essere eseguito mentre un amministratore è autenticato.
Come nasce una vulnerabilità XSS
Gli XSS non derivano semplicemente dall’aver dimenticato di eliminare la stringa <script>.
Il problema più generale riguarda il modo in cui dati non affidabili passano attraverso l’applicazione fino al punto in cui vengono interpretati.
Input, output e contesto sono tre problemi diversi
Tre operazioni vengono spesso confuse:
Validazione
Stabilisce se un dato appartiene all’insieme dei valori ammessi. Se un campo deve accettare solo un identificatore numerico, tutto ciò che non rispetta quella regola può essere rifiutato.
Sanitizzazione
Pulisce o normalizza un valore quando non è possibile definirlo attraverso una regola di validazione sufficientemente restrittiva.
Escaping dell’output
Trasforma il valore quando viene inserito nel documento affinché venga interpretato come dato, non come codice.
Non sono sinonimi e una sola di queste difese non può essere applicata indiscriminatamente in ogni situazione.
Perché filtrare semplicemente <script> non basta
Un approccio basato sulla ricerca di alcune stringhe considerate pericolose è fragile perché il browser può interpretare contenuti eseguibili in contesti differenti.
Il dato può finire:
- nel corpo HTML;
- dentro un attributo;
- in un URL;
- in JavaScript;
- nel DOM;
- in una porzione di HTML nella quale alcuni tag devono rimanere consentiti.
La difesa deve quindi essere context-aware.
È per questo che l’escaping di una URL non usa necessariamente la stessa funzione impiegata per una stringa visualizzata tra due tag HTML.
XSS e WordPress: dove può nascere il problema
WordPress offre API pensate per gestire in modo sicuro molti di questi casi, ma il CMS è estendibile per definizione.
Plugin, temi e codice personalizzato introducono nuovi punti nei quali un dato può entrare, essere trasformato, salvato e successivamente mostrato.
Per avere una visione più ampia delle altre superfici di rischio conviene affiancare questa guida alla nostra guida completa alla sicurezza WordPress.
Plugin, temi e WordPress Core
Considerare XSS esclusivamente un “problema dei plugin” è riduttivo.
Una vulnerabilità può emergere in qualunque componente che:
- acquisisca dati;
- li elabori;
- li restituisca in un contesto interpretabile dal browser.
Plugin e temi aumentano certamente la superficie applicativa, ma mantenere aggiornato anche il core resta indispensabile.
Quando è disponibile una security release, rimandare l’aggiornamento significa continuare a esporre codice per il quale potrebbe essere già nota una vulnerabilità. Se devi intervenire senza interrompere il sito, trovi la procedura nella guida su come aggiornare WordPress in sicurezza.
Form, commenti, shortcode, blocchi e dati dinamici
Tra i punti che meritano maggiore attenzione nello sviluppo WordPress ci sono:
- form personalizzati;
- shortcode;
- pagine di impostazioni;
- campi meta;
- dati dei profili utente;
- output prodotto da widget e blocchi;
- contenuti importati tramite API;
- HTML generato dinamicamente;
- attributi costruiti con dati variabili.
Non significa che questi elementi siano vulnerabili per definizione. Significa che sono luoghi nei quali input e output devono essere gestiti deliberatamente.
Anche un dato nel database può essere non affidabile
Uno degli errori più facili da commettere consiste nel fidarsi automaticamente di un valore perché è già stato salvato nel database.
La documentazione Security delle Common APIs di WordPress consiglia esplicitamente di non fidarsi neppure dei dati provenienti dal proprio database senza verificarne l’uso.
Un valore potrebbe infatti:
- essere stato inserito da un utente;
- provenire da un plugin;
- essere arrivato da un servizio esterno;
- essere stato salvato prima dell’introduzione di controlli più rigorosi;
- essere stato alterato durante una precedente compromissione.
Come prevenire XSS in WordPress
Per difendersi dagli attacchi XSS è utile pensare a una gerarchia, non a una lista di plugin.
La priorità è:
codice corretto → patching → validazione/sanitizzazione → escaping → ulteriori livelli di mitigazione
Mantieni aggiornati Core, plugin e temi
Gli aggiornamenti di sicurezza chiudono vulnerabilità note.
Questo non significa aggiornare alla cieca direttamente in produzione: su siti complessi resta prudente utilizzare backup, staging e verifiche di compatibilità.
Ma quando una versione installata è associata a una vulnerabilità XSS nota, continuare a utilizzarla senza una ragione operativa concreta aumenta inutilmente l’esposizione.
Se il componente è essenziale:
- verifica se esiste una release corretta;
- controlla eventuali advisory del vendor;
- applica la patch;
- verifica il comportamento del sito;
- rimuovi eventuali mitigazioni temporanee quando non servono più.
Se invece il componente è abbandonato e non esiste una correzione affidabile, la sostituzione può diventare una scelta più sensata del mantenimento indefinito.
Valida e sanitizza i dati in ingresso
La documentazione WordPress preferisce la validazione quando è possibile stabilire precisamente quali valori siano ammessi.
Quando l’input deve essere più libero, entra in gioco la sanitizzazione.
Per esempio:
$title = sanitize_text_field(
wp_unslash( $_POST['title'] ?? '' )
);
Questo è un esempio di sanitizzazione di un semplice campo testuale, non una funzione universale da applicare a qualsiasi tipo di input.
WordPress mette a disposizione funzioni specifiche come:
sanitize_text_field();sanitize_email();sanitize_file_name();sanitize_key();sanitize_url().
La documentazione WordPress sulla sanitizzazione raccoglie le funzioni principali e il loro utilizzo.
Esegui escaping dell’output nel contesto corretto
L’escaping è una delle difese più importanti contro XSS nel codice WordPress.
La regola pratica è: esegui l’escaping il più vicino possibile al momento in cui il valore viene stampato.
Un esempio:
echo '<a href="' . esc_url( $url ) . '">'
. esc_html( $label )
. '</a>';
Qui vengono utilizzate due funzioni diverse perché i dati finiscono in due contesti differenti:
esc_url()protegge la URL;esc_html()gestisce la stringa visualizzata nel contenuto HTML.
Altre funzioni importanti sono:
esc_attr()per gli attributi HTML;esc_textarea()per il contenuto delle textarea;esc_js()per casi JavaScript specifici;wp_kses()quando devi consentire soltanto un insieme controllato di elementi HTML;wp_kses_post()quando vuoi permettere l’HTML normalmente accettato nei contenuti WordPress.
La guida ufficiale di WordPress all’escaping contiene la distinzione fra i vari contesti.
Se devi consentire HTML, usa una allowlist reale
A volte eliminare tutto l’HTML non è possibile.
Potresti avere un campo che deve conservare link, corsivi e grassetti.
In questo scenario non conviene affidarsi a sostituzioni manuali di stringhe. Puoi definire quali elementi e attributi HTML siano effettivamente ammessi utilizzando wp_kses() oppure, quando appropriato, wp_kses_post().
Per esempio:
$allowed_html = array(
'a' => array(
'href' => array(),
'title' => array(),
),
'strong' => array(),
'em' => array(),
);
echo wp_kses( $content, $allowed_html );
Il punto non è copiare questo elenco in ogni progetto, ma permettere esplicitamente solo ciò che il caso d’uso richiede.
Content Security Policy: cosa può fare contro gli XSS
La Content Security Policy (CSP) è un meccanismo del browser che può limitare le risorse e gli script eseguibili da una pagina.
È molto utile come livello aggiuntivo contro XSS, ma non deve diventare un alibi per lasciare codice vulnerabile.
CSP è una mitigazione, non la correzione della vulnerabilità
Se un’applicazione inserisce dati non affidabili nell’output nel modo sbagliato, quella vulnerabilità continua a esistere anche in presenza di CSP.
Una policy efficace può rendere più difficile o impedire alcune forme di exploitation, ma la correzione primaria resta nel codice.
Per questo OWASP tratta CSP come defense in depth e non come sostituto di output encoding e sanitizzazione.
Una strict CSP è diversa da una semplice lista di domini
Un approccio storico consiste nel creare lunghe allowlist di domini dai quali è consentito caricare script.
Il problema è che queste policy possono diventare difficili da mantenere e possono autorizzare accidentalmente sorgenti che indeboliscono la protezione.
La documentazione MDN sulla Content Security Policy indica come approccio raccomandato per il controllo degli script una strict CSP basata su nonce o hash.
Concettualmente può assomigliare a:
Content-Security-Policy:
script-src 'nonce-{RANDOM_NONCE}';
object-src 'none';
base-uri 'none';
Questo frammento non va copiato alla cieca in produzione.
Un nonce CSP deve essere imprevedibile e associato correttamente agli script autorizzati. Inoltre non va confuso con i nonce di WordPress: condividono il nome, ma svolgono funzioni differenti.
Testa una CSP prima di applicarla in enforcement
Una CSP troppo restrittiva può rompere script legittimi, strumenti di analytics, widget, componenti del tema o plugin.
Prima di applicare una policy complessa in enforcement conviene quindi:
- inventariare gli script realmente necessari;
- costruire la policy;
- utilizzare inizialmente
Content-Security-Policy-Report-Onlyquando appropriato; - analizzare le violazioni;
- correggere la policy;
- passare all’enforcement dopo i test.
Su un sito WordPress ricco di plugin e integrazioni, improvvisare una CSP direttamente dentro functions.php senza conoscere il flusso delle risorse è spesso meno sicuro di quanto sembri.
Perché X-XSS-Protection non è più una soluzione consigliata
Nelle vecchie guide sulla sicurezza web è facile incontrare configurazioni come:
X-XSS-Protection: 1; mode=block
Questa non dovrebbe più essere considerata la difesa moderna da implementare contro gli XSS.
MDN classifica X-XSS-Protection come un header deprecato, non standard e non raccomandato per i nuovi progetti.
I browser moderni e le moderne strategie di sicurezza fanno affidamento su meccanismi diversi, in particolare su codice applicativo corretto e CSP.
Se sul tuo server l’header è presente per ragioni di compatibilità con browser legacy, va quindi valutato nel contesto dell’infrastruttura reale. Aggiungerlo oggi come principale protezione XSS non risolve la vulnerabilità.
Un WAF può bloccare un attacco XSS?
Un Web Application Firewall può intercettare e bloccare alcune richieste che corrispondono a pattern di attacco, ma non corregge la causa del problema.
Questa distinzione è fondamentale.
OWASP segnala che i WAF:
- cercano principalmente pattern conosciuti;
- possono essere aggirati;
- non risolvono il codice vulnerabile;
- possono non vedere classi di XSS che si manifestano esclusivamente lato client.
Il WAF va quindi trattato come un ulteriore livello di protezione.
Per capire dove si colloca nell’architettura di sicurezza puoi leggere la guida dedicata a come funziona un Web Application Firewall.
La sequenza corretta non è:
WAF → problema risolto
ma:
correzione della vulnerabilità + patching + difese applicative + eventuale WAF
Come verificare se WordPress è esposto a vulnerabilità XSS note
Per sapere se un sito utilizza componenti con vulnerabilità conosciute serve innanzitutto un inventario affidabile.
Controlla:
- versione del core;
- plugin installati;
- temi presenti;
- versioni effettivamente attive;
- componenti custom;
- advisory pubblicati dai vendor.
Per WordPress puoi utilizzare anche database di vulnerabilità e strumenti specializzati. Abbiamo dedicato una guida a WPScan e all’analisi della sicurezza di WordPress, utile per verificare componenti e vulnerabilità note su sistemi che sei autorizzato ad analizzare.
Una scansione automatica, però, non sostituisce una code review.
Un DOM-based XSS, un flusso applicativo custom o una particolare combinazione fra sorgente e output potrebbe richiedere analisi manuale del codice.
Non testare siti che non sei autorizzato a verificare
La ricerca di vulnerabilità deve avvenire sul tuo sito, su un ambiente di staging, in un laboratorio o su sistemi per i quali hai ricevuto un’autorizzazione esplicita.
Per un controllo difensivo è normalmente sufficiente partire da:
- inventario delle versioni;
- advisory conosciuti;
- code review;
- scanner autorizzati;
- verifica degli output dinamici;
- log e segnalazioni CSP, quando disponibili.
Cosa fare se scopri una vulnerabilità XSS sul tuo sito WordPress
Se individui una vulnerabilità non serve partire cancellando file a caso o installando più plugin di sicurezza.
La priorità è capire qual è il componente vulnerabile e se esiste già una correzione.
Identifica componente e versione interessata
Determina se il problema riguarda:
- WordPress Core;
- un plugin;
- un tema;
- codice personalizzato;
- JavaScript front-end;
- un’integrazione esterna.
Verifica quindi l’advisory e le versioni corrette.
Aggiorna, disattiva o sostituisci in base allo stato della patch
Se esiste una patch, applicala seguendo il normale processo di backup e test.
Se non esiste:
- valuta se il componente può essere disattivato;
- limita temporaneamente le funzionalità esposte;
- verifica se esiste un’alternativa mantenuta;
- applica misure compensative soltanto finché sono realmente necessarie.
Tenere indefinitamente online un componente vulnerabile semplicemente perché “c’è il firewall” non è una strategia di remediation.
Verifica se la vulnerabilità è stata realmente sfruttata
Vulnerabile non significa automaticamente compromesso.
La presenza di una falla e la prova che qualcuno l’abbia sfruttata sono due elementi distinti.
Se però esistono indicatori sospetti, controlla:
- account amministrativi;
- modifiche recenti ai file;
- plugin sconosciuti;
- attività nei log;
- contenuti o redirect inattesi;
- credenziali;
- eventuali persistence mechanism.
Se sospetti che il sito sia già stato compromesso, la procedura cambia: la guida su cosa fare con un sito WordPress hackerato parte proprio dall’isolamento e dall’analisi della compromissione, non dalla semplice installazione di un plugin.
Usa CSP e WAF come misure compensative, non come fine della remediation
Quando una patch non può essere applicata immediatamente, CSP e WAF possono in alcuni casi ridurre temporaneamente l’esposizione.
Ma il traguardo resta:
rimuovere o correggere il punto vulnerabile.
La mitigazione temporanea non deve diventare la normalità.
XSS, CSRF e SQL Injection non sono la stessa cosa
XSS viene spesso confuso con CSRF e SQL Injection perché tutte e tre sono vulnerabilità comuni delle applicazioni web.
Il meccanismo, però, è differente.
| Vulnerabilità | Obiettivo principale | Meccanismo tipico | Difesa centrale |
|---|---|---|---|
| XSS | Browser e contesto dell’utente | Dati non sicuri interpretati come contenuto eseguibile | Escaping contestuale, sanitizzazione, safe sinks |
| CSRF | Azioni dell’utente autenticato | Richiesta indesiderata eseguita con la sessione della vittima | Token anti-CSRF/nonces, SameSite, verifica dell’intento |
| SQL Injection | Database | Input interpretato come parte della query SQL | Query parametrizzate / prepared statements |
Su WordPress i nonce vengono utilizzati per verificare l’intenzione associata a determinate richieste e sono quindi importanti soprattutto contro CSRF.
Non sostituiscono l’escaping dell’output necessario contro XSS.
Allo stesso modo, $wpdb->prepare() è fondamentale per costruire query SQL parametrizzate, ma non è la difesa da utilizzare quando stai stampando una stringa nell’HTML.
FAQ sugli attacchi XSS
XSS e Cross-Site Scripting significano la stessa cosa?
Sì. XSS è l’abbreviazione comunemente utilizzata per Cross-Site Scripting. La sigla XSS viene usata per evitare l’ambiguità che avrebbe l’acronimo CSS, già associato ai Cascading Style Sheets.
Un attacco XSS può colpire anche WordPress aggiornato?
Aggiornare WordPress, temi e plugin riduce l’esposizione alle vulnerabilità già corrette, ma non garantisce che non possano esistere vulnerabilità sconosciute o problemi introdotti da codice personalizzato e integrazioni.
L’aggiornamento è quindi una misura necessaria, non l’unica difesa.
Un plugin di sicurezza elimina le vulnerabilità XSS?
No. Un plugin di sicurezza può aggiungere scanner, firewall, monitoraggio o altre protezioni, ma non può essere considerato un sostituto della correzione del codice vulnerabile.
Se un componente gestisce in modo scorretto dati non affidabili, la soluzione migliore è correggere o sostituire quel componente.
CSP impedisce tutti gli attacchi XSS?
No. Una Content Security Policy ben progettata può impedire o rendere molto più difficile l’exploitation di numerosi XSS, ma non elimina automaticamente il difetto applicativo.
CSP funziona meglio come ulteriore livello di difesa sopra codice correttamente progettato.
Conclusione
Difendersi dagli attacchi XSS non significa trovare un’impostazione da attivare una volta per tutte.
La priorità è capire dove entrano i dati, come vengono trasformati e in quale contesto vengono restituiti al browser.
Su WordPress questo significa soprattutto:
- mantenere core, plugin e temi aggiornati;
- validare e sanitizzare gli input;
- eseguire escaping dell’output nel contesto corretto;
- utilizzare le API native di WordPress invece di costruire filtri improvvisati;
- verificare i componenti rispetto alle vulnerabilità conosciute;
- utilizzare CSP e WAF come livelli aggiuntivi, non come sostituti della correzione.
Se trovi una vulnerabilità, correggere il componente è meglio che affidarsi indefinitamente a una mitigazione. Se invece ci sono segnali che il sito sia già stato compromesso, il problema non è più soltanto prevenire un XSS: serve capire cosa è successo, chi ha avuto accesso e quali modifiche sono rimaste nel sistema.
In quel caso un’analisi tecnica completa è molto più utile di un’altra regola aggiunta al firewall.