Instalar un plugin de seguridad y dar por hecho que ya estás protegido es el error más repetido en WordPress. Un plugin vigila; una auditoría comprueba. Son cosas distintas, y solo la segunda te dice dónde estás realmente expuesto.
La buena noticia es que una auditoría de seguridad, que hace unos años exigía leer decenas de páginas de documentación, hoy se puede hacer con la inteligencia artificial como copiloto en una tarde. La mala es que hay una parte que la IA no debe decidir por ti, y conviene tenerla clara desde el principio.
Qué aporta la IA en una auditoría de seguridad (y qué no)
Conviene ser honesto antes de empezar, porque hay mucha promesa inflada sobre esto.
La IA es muy buena en:
- Leer un listado largo de plugins con sus versiones y decirte cuáles llevan años sin actualizarse.
- Traducir un aviso técnico de vulnerabilidad a un lenguaje que entiendas.
- Revisar un fichero de configuración y señalar líneas sospechosas.
- Priorizar: ordenar veinte hallazgos por riesgo real en lugar de dejarte una lista plana.
- Redactar el informe final para que puedas pasárselo a un cliente o a tu equipo.
La IA no debe hacer:
- Decidir si una vulnerabilidad te afecta. Eso se comprueba contra la base de datos oficial, no se pregunta.
- Confirmar que una web está limpia. Un modelo puede afirmarlo con toda seguridad y estar equivocado.
- Ejecutar cambios en producción. La IA propone, tú aplicas, y siempre con copia de seguridad delante.
Con esa frontera clara, vamos al procedimiento.
Paso 1: levanta el inventario
No puedes auditar lo que no sabes que tienes. El primer paso es una lista completa de lo que corre en tu WordPress: versión del núcleo, tema activo, tema padre si usas uno hijo, todos los plugins (activos e inactivos) con su número de versión, y la versión de PHP.
El detalle que casi todo el mundo pasa por alto: los plugins desactivados también son código presente en el servidor. Un plugin desactivado con una vulnerabilidad conocida sigue siendo un fichero al que se puede llegar por URL. Si no lo usas, no lo desactives: bórralo.
Para sacar el listado sin instalar nada, ve a Plugins > Plugins instalados, selecciona todo el texto de la tabla y pégalo en un documento. En Strumenti > Salute del sito > Informazioni tienes la versión de PHP, la del servidor y la de la base de datos, todo junto y copiable con un botón.
Si mantienes varias webs, este inventario merece vivir en una hoja de cálculo y actualizarse cada trimestre. Es la base de todo lo demás.
Passo 2: confronta con vulnerabilità note
Qui c'è il passo che la maggior parte delle persone salta e quello che evita più problemi.
Esistono database pubblici che registrano le vulnerabilità pubblicate di plugin e temi di WordPress. Le due di riferimento sono WPScan y Patchstack. Entrambe hanno un motore di ricerca web gratuito: inserisci il nome del plugin e ti dice se ci sono vulnerabilità registrate e in quali versioni.
La procedura corretta è questa:
- Prendi il tuo inventario del passo 1.
- Chiedi all'IA di ordinarti la lista per anzianità dell'ultimo aggiornamento, marcando quelli che non vengono toccati da più di un anno.
- Busca uno per uno in WPScan o Patchstack quelli che l'IA ha marcato.
- Annota: nome, versione che hai, versione corretta, gravità.
Fai attenzione all'ordine. L'IA delimita il lavoro —ti dice cosa guardare per primo— ma il controllo lo fai tu contro la fonte ufficiale. Chiedere direttamente a un modello «il plugin X versione 2.1 ha vulnerabilità?» è una cattiva idea: i dati sulle vulnerabilità cambiano ogni settimana e il modello può rispondere con sicurezza su qualcosa che non sa.
Se un plugin ha una vulnerabilità senza patch disponibile, la decisione non è tecnica ma di business: cercare un'alternativa, o assumere il rischio documentandolo. Nella nostra guida su come aggiornare i plugin di WordPress in modo sicuro spieghiamo come applicare questi aggiornamenti senza rompere il sito web lungo il percorso.
Passo 3: controlla utenti e accessi
La via d'ingresso più comune non è una vulnerabilità esotica: è un account che non dovrebbe esistere o una password debole.
En Utenti, controlla:
- Quanti amministratori ci sono. Dovrebbero essere i minimi indispensabili. Ogni amministratore è una chiave maestra.
- Account di persone che non ci sono più: l'agenzia precedente, lo stagista dell'estate scorsa, lo sviluppatore di quell'incarico specifico.
- Account con nome generico come «admin», «wordpress» o «test».
- Data dell'ultimo accesso, se il tuo plugin di sicurezza la registra. Un account amministratore che nessuno usa da otto mesi è un rischio senza contropartita.
E sulle password: non riutilizzarne nessuna, e che siano lunghe. Puoi crearne una in due secondi con il nostro generatore di password sicure, che funziona nel tuo browser senza inviare nulla a nessun server.
Attiva inoltre la verifica in due passaggi per tutti gli account amministratore. È la misura che ha il miglior rapporto sforzo-protezione di tutta questa lista.
Passo 4: controlla l'integrità dei file
WordPress pubblica le somme di controllo di tutti i file di ogni versione del core. Questo permette di rilevare se qualcuno è stato modificato.
I plugin di sicurezza seri includono questo controllo. In Wordfence si trova in Scan, e confronta i tuoi file del core, temi e plugin del repository ufficiale con gli originali. Se appare un file modificato che tu non hai toccato, lì hai qualcosa da investigare.
Due avvisi importanti sui risultati:
- I falsi positivi esistono. Un tema figlio, uno snippet proprio o una personalizzazione legittima appariranno come «modificato». Questo non è un attacco.
- Che non esca nulla non significa che tu sia pulito. Un file malevolo nuovo in una cartella di caricamento non appare come «modificato» perché non c'era un originale con cui confrontarlo.
Qui l'IA aiuta davvero: incollale il contenuto di un file sospetto e chiedile di spiegarti cosa fa. È particolarmente brava a rilevare codice offuscato —quelle linee lunghissime piene di base64_decode y eval che non hanno alcuna ragione legittima per essere in un tema. Se hai già indizi che il sito web è compromesso, la nostra guida alla pulizia di un WordPress sotto attacco copre il processo completo di disinfezione, che è un lavoro diverso da questo audit.
Passo 5: audita la configurazione
Questa è la parte in cui l'IA rende meglio, perché si tratta di leggere la configurazione e rilevare le deviazioni.
Controlla questi punti:
- Modifica dei file dal desktop. Se un attaccante entra con un account amministratore, l'editor di temi gli dà esecuzione diretta del codice. Si disattiva con
define('DISALLOW_FILE_EDIT', true);enwp-config.php. - Debugging in produzione.
WP_DEBUGdeve essere afalsesu un sito web in produzione. Se è attivo, i messaggi di errore possono rivelare percorsi del server. - Permessi dei file. L'abituale è 644 per i file e 755 per le cartelle. Nulla dovrebbe essere a 777.
- XML-RPC. Se non usi l'applicazione mobile di WordPress né Jetpack, probabilmente non ne hai bisogno, ed è un obiettivo abituale di attacchi di forza bruta.
- Elenco di directory. Entra en
tudominio.com/wp-content/uploads/. Se vedi un elenco di cartelle invece di un errore, hai l'elenco di directory attivo ed è opportuno disattivarlo. - Versione di PHP. Una versione senza supporto non riceve patch di sicurezza. Abbiamo una guida su come aggiornare PHP in WordPress senza prendere spaventi.
Un prompt che funziona bene per questa fase, incollando sotto il tuo wp-config.php con le credenziali del database e le chiavi di sicurezza cancellate:
«Sei un auditor di sicurezza di WordPress. Ti passo un wp-config.php con i dati sensibili già eliminati. Rivedi la configurazione e dimmi: quali costanti di sicurezza raccomandate mancano, quali impostazioni sono inadeguate per un ambiente di produzione, e cosa trovi che non sia standard di un'installazione normale. Ordina i risultati per rischio, dal maggiore al minore, e per ognuno spiega la conseguenza concreta se viene sfruttato. Non inventare: se qualcosa non puoi determinarlo con ciò che ti ho dato, dillo.»
Quell'ultima frase è importante. Chiedere esplicitamente che riconosca ciò che non sa riduce molto le risposte inventate.
Passo 6: revisiona le intestazioni di sicurezza
Le intestazioni HTTP sono istruzioni che il tuo server invia al browser del visitatore. Ben impostate, chiudono intere famiglie di attacchi.
Controlla le tue in un analizzatore gratuito come securityheaders.com: inserisci il tuo dominio e ti dà un voto con ciò che manca. Quelle che contano di più sono Strict-Transport-Security, che obbliga a usare HTTPS sempre; X-Content-Type-Options, che impedisce al browser di indovinare i tipi di file; e Content-Security-Policy, la più potente e anche la più facile da configurare male.
Su quest'ultima, un consiglio pratico: una CSP scritta male rompe il sito web, e di solito rompe proprio ciò che genera denaro (il modulo, il gateway di pagamento, la chat). Se la implementi, fallo prima in modalità solo-report per alcuni giorni per vedere cosa bloccherebbe prima di applicarla davvero.
Passo 7: trasforma i risultati in un piano
Un audit che termina con un elenco di venti cose sparse non serve a nulla, perché nessuno sa da dove iniziare. Qui è dove l'IA chiude il cerchio.
Passagli tutti i tuoi risultati e chiedigli di organizzarli così:
«Ti passo i risultati di un audit di sicurezza di WordPress. Organizzali in una tabella con queste colonne: risultato, rischio (alto/medio/basso), sforzo di correzione (minuti/ore/giorni) e ordine di esecuzione raccomandato. Dai priorità in base al rischio diviso per lo sforzo, in modo che la prima cosa sia ciò che protegge di più con meno lavoro. Aggiungi una colonna finale indicando se il cambiamento può rompere il sito web e deve essere fatto in un ambiente di test.»
Quell'ultima colonna è quella che ti risparmia il dispiacere. Ci sono correzioni che applichi a caldo senza paura, e altre —modificare i permessi, cambiare la versione di PHP, inserire una CSP— che vengono testate prima in un ambiente di prova.
I limiti: quando questo non basta
Tutto quanto sopra è un audit di configurazione e superficie di attacco. Copre la stragrande maggioranza dei casi reali, perché la stragrande maggioranza dei WordPress compromessi lo sono a causa di un plugin obsoleto o di una password debole, non per un attacco sofisticato.
Ci sono situazioni in cui questo non è sufficiente ed è opportuno che lo esamini una persona:
- Ci sono già indizi di compromissione: reindirizzamenti strani, spam nei risultati di Google, avvisi del browser. Questo non è più un audit, è una risposta a un incidente, e l'ordine dei compiti è completamente diverso.
- Il sito web gestisce pagamenti o dati personali sensibili. Qui entrano in gioco obblighi legali che nessuno strumento automatico valuterà per te.
- C'è sviluppo su misura. Un plugin proprietario o un tema fatto a mano hanno il proprio codice, e quel codice nessuno lo ha mai revisionato. Un audit di configurazione non lo copre.
- È un sito web critico per il business. Se un giorno di inattività ti costa più di quanto costa una revisione professionale, il conto torna da sé.
Domande frequenti
Ogni quanto dovrei fare l'audit del mio WordPress?
Una revisione completa come quella di questa guida, due volte all'anno. La verifica delle vulnerabilità del passo 2, ogni mese: è quella che scade più rapidamente, perché nuove vulnerabilità vengono pubblicate ogni settimana. E sempre dopo un grande cambiamento, come l'aggiunta di un plugin importante o il cambio di tema.
Posso passare il mio wp-config.php intero a un'IA?
No senza pulirlo prima. Quel file contiene l'utente e la password del tuo database e le chiavi di sicurezza delle sessioni. Cancella quei valori, sostituiscili con testo generico e allora sì che puoi chiedere la revisione. Lo stesso vale per qualsiasi file di log che possa contenere indirizzi IP o dati utente.
Un plugin di sicurezza sostituisce l'audit?
No, fanno cose diverse. Il plugin è una sorveglianza continua: blocca i tentativi di accesso, filtra il traffico e avvisa dei cambiamenti. L'audit è una revisione puntuale per verificare se la tua configurazione è corretta e il tuo software è aggiornato. Un plugin di sicurezza perfettamente configurato non ti protegge da un plugin con una vulnerabilità nota che non aggiorni da due anni. Se vuoi sfruttare al massimo il tuo, abbiamo una guida su impostazioni poco conosciute di Wordfence.
Cosa faccio se trovo qualcosa di grave?
Prima di toccare qualsiasi cosa, backup completo: file e database. Poi applica la correzione in un ambiente di test se il cambiamento è delicato, e in produzione se è banale (aggiornare un plugin, eliminare un account). Se quello che hai trovato è un file malevolo, non limitarti a cancellarlo: quasi mai vengono da soli, e bisogna scoprire da dove è entrato o riapparirà.
Per finire
L'intelligenza artificiale non fa l'audit per te, ma trasforma un compito da specialista in qualcosa che puoi fare tu con metodo. Ti delimita dove guardare, ti traduce il linguaggio tecnico e ti ordina il risultato in un piano eseguibile.
Ciò che non delega è il criterio: quale rischio ti assumi, cosa verifichi rispetto alla fonte ufficiale e quali modifiche provi prima di applicare. Quella parte è ancora tua, ed è proprio quella che fa la differenza tra un audit vero e proprio e un elenco di raccomandazioni generiche.
Se vuoi continuare qui, nella nostra libreria di strumenti gratuiti hai utilità che funzionano interamente nel tuo browser, senza caricare nulla su nessun server.
