Nel 2025 sono stati compromessi in media 30.000 siti web al giorno (fonte: Forbes). La maggior parte delle vittime non erano target deliberati: erano semplicemente i siti più vulnerabili scoperti dai bot automatici. La sicurezza web non è un problema "da grandi aziende" — è un problema di qualunque sito con contenuto o traffico. Le PMI italiane sono spesso bersagli preferenziali proprio perché hanno le stesse vulnerabilità delle grandi aziende ma meno risorse per difendersi.
I vettori di attacco più comuni nel 2026
- Brute force login: tentativi massivi di indovinare password di wp-admin, cPanel, FTP
- SQL injection: inserimento di codice malevolo nei form per estrarre dati dal database
- Cross-Site Scripting (XSS): iniezione di script nei campi non sanitizzati
- Plugin/tema vulnerabile: sfruttamento di CVE note in software non aggiornato
- Credential stuffing: riutilizzo di password rubate da altri breach
- DDoS: flood di traffico per rendere il sito irraggiungibile
- Malvertising e supply chain attack: codice malevolo in dipendenze di terze parti
WordPress: le vulnerabilità specifiche da conoscere
WordPress copre il 43% dei siti web mondiali, il che lo rende il target principale. Le vulnerabilità più sfruttate nel 2025 riguardano plugin non aggiornati (85% dei casi, fonte: Sucuri). Il database WPScan registra oltre 57.000 vulnerabilità documentate per plugin WordPress. Misure minime: non usare mai username "admin" (è il primo che viene tentato negli attacchi brute force), aggiornare ogni plugin entro 48h da una release di sicurezza, disabilitare i plugin non utilizzati (anche se disattivati, il codice è presente sul server e può essere sfruttato).
Una vulnerabilità specifica di WordPress che vediamo spesso nei nostri audit è l'esposizione del file xmlrpc.php. Questo endpoint, usato in passato per le app mobile WordPress, è quasi sempre inutile per i siti aziendali moderni ma viene sfruttato per attacchi brute force amplificati (1 richiesta a xmlrpc.php può testare centinaia di password in simultanea). La soluzione è semplice: disabilitare xmlrpc.php completamente via .htaccess o tramite un plugin come Disable XML-RPC.
Cloudflare WAF: la prima linea di difesa
Cloudflare Web Application Firewall (WAF) filtra il traffico malevolo prima che raggiunga il tuo server, bloccando SQL injection, XSS, e attacchi DDoS. Il piano gratuito di Cloudflare include protezione DDoS base, CDN e SSL. Il piano Pro (20€/mese) aggiunge WAF con regole managed, firewall avanzato, e bot management. Il piano Business (200€/mese) è consigliato per e-commerce con dati di pagamento. Sucuri offre un'alternativa specializzata con firewall cloud e cleanup malware garantito incluso nel piano (a differenza di Cloudflare che non include il cleanup).
L'implementazione di Cloudflare richiede il cambio dei nameserver del dominio — un'operazione semplice ma che richiede 24-48h di propagazione DNS. Durante questo periodo, il sito resta accessibile grazie al TTL dei record DNS. Nei nostri progetti gestiamo questa transizione durante orari notturni per minimizzare l'impatto. Dopo l'attivazione, Cloudflare Analytics fornisce dati preziosi sulle minacce bloccate: tipicamente un sito medio riceve 20-50 richieste malevole bloccate al giorno — un numero che sorprende sempre i clienti che pensavano di essere "troppo piccoli per essere attaccati".
Checklist sicurezza base da implementare oggi
- HTTPS con certificato SSL valido (Let's Encrypt è gratuito)
- Password admin complessa (20+ caratteri) + autenticazione a due fattori
- Limitare i tentativi di login (Wordfence, plugin dedicato)
- Aggiornamento automatico del core CMS + aggiornamento manuale testato dei plugin
- Header di sicurezza HTTP (CSP, HSTS, X-Frame-Options)
- Scansione malware settimanale con Sucuri SiteCheck o Wordfence
- Log di accesso attivi e monitorati
- Blocco accesso diretto a wp-admin per IP non autorizzati (se IP fisso)
Header di sicurezza HTTP: la configurazione base
Gli header HTTP di sicurezza sono istruzioni inviate dal server al browser che limitano cosa il browser può fare con il contenuto della pagina. I più importanti: `Content-Security-Policy (CSP)` definisce da quali domini possono essere caricate risorse (script, immagini, font) — blocca gli attacchi XSS; `Strict-Transport-Security (HSTS)` forza HTTPS per 1 anno (max-age=31536000); `X-Frame-Options: DENY` impedisce che il sito venga embeddato in iframe su altri siti (previene clickjacking); `X-Content-Type-Options: nosniff` impedisce al browser di "indovinare" il tipo di contenuto. Verifica la configurazione del tuo sito su securityheaders.com.
Cosa fare se il sito è già stato compromesso
Primo: non farsi prendere dal panico e non procedere in modo affrettato. Sequenza corretta: 1) Portare il sito in manutenzione (pagina statica temporanea) per evitare che i visitatori vengano infettati. 2) Identificare la data approssimativa della compromissione dai log di accesso. 3) Ripristinare da un backup precedente all'attacco. 4) Identificare il vettore di accesso con audit del codice e dei log. 5) Chiudere il vettore (aggiornamento plugin vulnerabile, cambio credenziali, hardening). 6) Cambiare tutte le credenziali (admin, database, FTP, hosting, email). 7) Richiedere la rimozione dalla blacklist Google tramite Search Console.
Il nostro servizio di gestione siti include interventi di emergenza per siti compromessi con SLA garantito. Nei casi che abbiamo gestito, il ripristino completo da un backup pulito più il hardening post-attacco richiede mediamente 4-8 ore di lavoro tecnico. L'alternativa — cercare manualmente e rimuovere ogni file infetto senza un backup pulito — può richiedere giorni e non garantisce la rimozione completa. Per prevenire il problema, il servizio web master garantisce monitoraggio continuo e allerta immediata. Per informazioni sui piani disponibili, visita la pagina contatti.
