Perché WordPress è un rischio di sicurezza per le applicazioni aziendali

WordPress è uno straordinario successo del mondo open source. In vent'anni è cresciuto da semplice strumento per blog personali a piattaforma che alimenta oltre il 43% di tutti i siti web del mondo. Ma questa massiccia adozione è diventata un'arma a doppio taglio per le aziende — e un problema di sicurezza che non può semplicemente essere ignorato.

Questo articolo non è un manifesto contro WordPress. È un'analisi sobria di ciò che accade quando si costruisce un'applicazione aziendale su uno strumento progettato per uno scopo diverso — e di quanto effettivamente costi.

I numeri sulla sicurezza che parlano da soli

Il database WPScan traccia oltre 57.000 vulnerabilità documentate in plugin, temi e core di WordPress. In media, vengono pubblicati 50–70 nuovi CVE ogni settimana. Il rapporto annuale di Sucuri sui siti compromessi rileva che il 96% di tutti i CMS infettati è WordPress (il che in parte riflette la sua quota di mercato dominante). La domanda non è più "il mio sito sarà preso di mira?" — ma "quando, e attraverso quale vettore?"

Come si svolge un attacco nella pratica

Gli attaccanti non si affidano solo alla forza bruta. Lavorano in modo sistematico con strumenti automatizzati:

1. Fingerprinting — Uno scanner automatico identifica la versione di WordPress, i plugin installati e le loro versioni (file come readme.txt, wp-includes/version.php e gli header HTTP sono pubblicamente accessibili senza alcuna autenticazione).
2. CVE matching — Lo scanner confronta le versioni rilevate con un database di vulnerabilità. Se trova un CVE noto, passa immediatamente all'exploit.
3. Sfruttamento — Vettori comuni: SQL injection in un plugin, upload non autenticato di file, XSS che porta al furto di cookie di sessione, brute-forcing su /wp-login.php e sull'endpoint XML-RPC.
4. Persistenza — L'attaccante carica una webshell, crea un account amministratore backdoorato o inserisce un payload cifrato nel database (wp_options) che si attiva ad ogni caricamento della pagina.

L'intero processo — dalla scansione iniziale alla compromissione completa — richiede in media nel giro di poche ore dalla divulgazione del CVE. La maggior parte degli operatori aggiorna i plugin manualmente e in modo irregolare.

Plugin: la superficie d'attacco più grande

Il core di WordPress è oggi ragionevolmente ben mantenuto. Il vero problema è l'ecosistema di plugin:

• Oltre 60.000 plugin nel repository ufficiale, più migliaia di quelli commerciali.
• I plugin sono scritti da sviluppatori con livelli molto diversi di consapevolezza della sicurezza — da professionisti a hobbisti.
• L'installazione WordPress media utilizza 22 plugin attivi.
• Ogni plugin aggiunge codice di terze parti con accesso diretto al database, al filesystem e alle richieste HTTP.
• Un plugin può essere venduto a un nuovo proprietario in qualsiasi momento. Nel 2021, il popolare plugin AccessPress Themes è stato deliberatamente backdoorato dopo l'acquisizione, compromettendo oltre 360.000 siti secondo l'analisi di sicurezza di Jetpack.

Con il codice personalizzato, la superficie d'attacco è esattamente quella che si crea intenzionalmente. Nessun codice di terze parti con privilegi sul database. Nessun plugin il cui autore decida di vendere il progetto o abbandonarlo.

XML-RPC e /wp-login.php: porte sempre aperte

WordPress viene fornito con due endpoint costantemente sotto attacco automatizzato:

• /wp-login.php — La pagina di login, accessibile senza alcuna protezione per impostazione predefinita.
• xmlrpc.php — Progettato originariamente per la pubblicazione remota, oggi usato principalmente per il brute-forcing delle credenziali (una singola chiamata HTTP può testare centinaia di password contemporaneamente tramite multicall) e come vettore DDoS.

Entrambi possono essere bloccati, ma ciò richiede passi consapevoli e manutenzione continua — perché gli aggiornamenti del core di WordPress possono riattivarli.

Prestazioni: numeri concreti

Un caricamento tipico di una pagina WordPress attiva 15–80 query al database e carica decine di file PHP solo dal core. Ecco i dati di misurazione provenienti dai miei progetti reali:

• Sito WordPress medio: punteggio Google PageSpeed 45–65 (senza caching aggressivo).
• Stesso contenuto su un'applicazione personalizzata: 90–98 senza sforzi particolari.
• Time to First Byte (TTFB): WordPress tipicamente 600–1.200 ms, applicazione PHP personalizzata 80–200 ms.

PageSpeed non è solo una metrica UX. Google la usa come fattore di posizionamento dall'aggiornamento dei Core Web Vitals. Un sito lento significa posizioni più basse nei risultati di ricerca e meno clienti.

Vendor Lock-In: la trappola dei plugin

Le funzionalità che WordPress non offre nativamente vengono coperte da plugin in abbonamento:

• WooCommerce + estensioni essenziali: $150–500/anno
• Form builder avanzati (Gravity Forms): $160–260/anno
• Plugin per membership: $150–300/anno
• Backup e sicurezza: $100–200/anno

Smetti di pagare? Perdi gli aggiornamenti e gestisci software vulnerabile. Passi a un outro plugin? La migrazione dei dati e la riconfigurazione costano ore o giorni. Il codice personalizzato è un investimento una tantum — e ti appartiene per sempre.

Aggiornamenti come una roulette russa

Ogni aggiornamento di plugin è una scommessa. Con più di 20 plugin scritti da 20 autori diversi, i conflitti dopo un aggiornamento sono statisticamente inevitabili. Risultato: il sito si rompe alle 3 del mattino, i clienti vedono una pagina di errore e tu chiami lo sviluppatore nel panico. Rimandi l'aggiornamento? Utilizzi software vulnerabile che i bot scansionano continuamente. Nessuna opzione è buona.

Quando WordPress ha senso

Siamo onesti. WordPress ha il suo posto, dove ha perfettamente senso:

• Un blog aziendale o un sito PR senza dati sensibili o database utenti
• Un semplice sito di catalogo con aggiornamenti di contenuto non frequenti
• Un progetto con budget limitato dove le funzionalità di base sono sufficienti
• Un team in cui i contenuti sono gestiti da utenti non tecnici e uno sviluppatore è disponibile per la manutenzione regolare

Ma nel momento in cui il tuo sito elabora dati personali dei clienti, pagamenti, documenti aziendali o accessi sensibili — stai scegliendo consapevolmente il CMS più attaccato al mondo come custode di tali dati.

Cosa offre lo sviluppo personalizzato

Un'applicazione personalizzata non è automaticamente sicura solo perché non è WordPress. La sicurezza è il risultato di scelte deliberate. Ogni applicazione DubNet CZ include:

• PDO prepared statements — nessun SQL inline; SQL injection eliminata a livello architetturale.
• Token CSRF su tutti i form che modificano lo stato.
• Rate limiting del login per IP con backoff esponenziale.
• Header Content Security Policy (CSP) che limitano le sorgenti permesse di script e stili.
• HSTS per HTTPS forzato e protezione contro SSL stripping.
• Audit log per tutti i login, le modifiche ai dati e le azioni amministrative.
• Privilegi minimi sul database — l'utente DB dell'applicazione non ha diritti CREATE/DROP.
• 2FA per tutti gli accessi amministrativi.

Conclusione: la decisione ha un costo

WordPress è uno strumento legittimo se usato nel contesto giusto. Per un'applicazione aziendale che gestisce dati dei clienti, pagamenti o informazioni sensibili, introduce un rischio di sicurezza sistemico che non può essere eliminato completamente — solo gestito, al costo di tempo e denaro continuativi.

Lo sviluppo personalizzato costa di più all'inizio. Nel corso di 2–3 anni, il costo totale diventa comparabile. E per tutto quel tempo, gestisci un sistema di cui conosci ogni riga di codice, la cui superficie d'attacco è minima e la cui sicurezza non dipende dalle decisioni di sviluppatori anonimi di plugin di terze parti.

Vuoi sapere come sarebbe una soluzione personalizzata per il tuo caso? Contattami — la consulenza iniziale è gratuita.