12 passi per mettere in sicurezza WordPress su Linux con Nginx

WordPress è una delle piattaforme più diffuse sul Web, ma anche una delle più bersagliate. Circa il 43% dei siti ne fanno uso: tanto che WordPress è al momento, in assoluto, il CMS più installato e utilizzato. Può funzionare sfruttando diverse configurazioni lato server, ma una delle più diffuse è l’architettura LEMP (Linux, Nginx, MySQL/MariaDB, PHP). Ogni componente espone superfici d’attacco che possono essere oggetto di abusi, se non adeguatamente protette.

Neutralizzare le potenziali vulnerabilità di WordPress ispirandosi al modello OWASP

Ricorrendo ad esempio all’accoppiata Ubuntu più Nginx per ospitare un sito WordPress, è fondamentale mettere in atto una strategia di hardening server-side, seguendo le indicazioni dell’OWASP Top 10, framework globale di riferimento per la sicurezza delle applicazioni Web.

Queste categorie, dall’injection al controllo degli accessi, rappresentano i rischi più comuni e impattanti; servono come guida per gli sviluppatori e amministratori di sistema. Applicare OWASP Top 10 a WordPress significa:

• Ridurre i vettori di attacco più comuni.
• Rispettare best practice di sicurezza riconosciute a livello globale.
• Rafforzare la sicurezza sia lato codice che lato server.

Rimozione del file readme.html

WordPress, per impostazione predefinita, colloca un file readme.html nella cartella radice del sito. Sebbene apparentemente innocuo, questo file può rivelare dettagli critici come la versione esatta della piattaforma in uso. Gli attaccanti sfruttano questi dati per lanciare exploit specifici contro versioni vulnerabili. Rimuoverlo è una forma basilare ma importante di offuscamento, che rientra nella categoria OWASP “Security Misconfiguration“.

Per risolvere il problema, si può intervenire a livello di file system eliminando il file:

rm -f /var/www/html/readme.html

oppure via Nginx:

location = /readme.html {
    deny all;
}

Abilitare un CAPTCHA sulla pagina di login

Le pagine di login WordPress sono tra gli obiettivi principali dei bot automatici e degli attacchi a dizionario. L’integrazione di un CAPTCHA, soprattutto quelli invisibili o intelligenti (come reCAPTCHA v3), può interrompere del tutto gli attacchi automatizzati, imponendo una barriera a chi tenta di guadagnare l’accesso al sito usando molteplici tentativi. Questo è un punto chiave per mitigare le Authentication Failures, categoria A07 OWASP.

Oltre al reCATCHA v3 di Google, si possono installare e utilizzare plugin come BestWebSoft e WPForms.

Abilitare l’autenticazione a due fattori (2FA)

Anche la password più complessa può essere trafugata tramite phishing, keylogger o leak a livello di database. Per proteggere gli account amministrativi, l’autenticazione a due fattori aggiunge un ulteriore livello di sicurezza: oltre alla password, l’utente deve fornire un codice generato temporaneamente (OTP) o un token. Si tratta di una delle misure più efficaci e semplici contro le compromissioni delle credenziali, e viene citata espressamente nel framework OWASP.

Tra plugin WordPress consigliati per gestire la 2FA: Wordfence Login Security e Two Factor.

Blocco di xmlrpc.php

Il file xmlrpc.php di WordPress consente la pubblicazione remota e altre operazioni via XML-RPC. Tuttavia, è spesso usato come vettore per amplificare attacchi DDoS o bypassare sistemi di autenticazione. Se non è strettamente necessario per il funzionamento del sito, conviene bloccarlo per evitare l’esposizione di superfici di attacco superflue. Rientra nelle configurazioni errate descritte in OWASP A05.

Per disattivare l’accesso a xmlrpc.php si può procedere come segue via Nginx:

location = /xmlrpc.php {
    deny all;
}

In alternativa, tramite codice PHP:

add_filter('xmlrpc_enabled', '__return_false');

La riga deve essere aggiunta nel file functions.php, alla fine o subito dopo l’apertura PHP, ma sempre fuori da funzioni già esistenti.

Abilitazione della registrazione di eventi legati alla sicurezza

Una buona strategia di sicurezza non si limita alla prevenzione, ma comprende anche la rilevazione tempestiva e la risposta agli incidenti. Abilitare il logging delle azioni utente (login, modifiche, caricamenti, errori) consente di rilevare comportamenti sospetti, identificare eventuali compromissioni e fornire elementi utili in caso di auditing. L’assenza di tracciabilità è uno dei punti deboli più comuni secondo OWASP A09.

Per trattare questo punto, si possono installare e adoperare plugin come WP Security Audit Log e Wordfence con logging attivo.

Disattivazione dell’editor di file lato backend

WordPress include un editor PHP direttamente accessibile dal backend, che consente di modificare temi e plugin. Questa funzionalità, seppur comoda per piccoli interventi, è altamente pericolosa in caso di compromissione dell’account: un attaccante potrebbe caricare codice malevolo (web shell, backdoor,…). Disabilitarlo è perciò un passo fondamentale per impedire la persistenza dell’attacco e rientra tra i problemi di integrità del codice secondo OWASP A08.

La soluzione consiste nell’aggiungere la seguente riga PHP all’interno del file wp-config.php:

define('DISALLOW_FILE_EDIT', true);

Limitare l’accesso alla REST API

La REST API di WordPress è uno strumento potente per l’interazione programmata, ma può anche esporre dati riservati, come la lista utenti o metadati non pubblici. Gli attaccanti possono utilizzarla per condurre attività di enumeration e reconnaissance. È essenziale quindi restringerne l’uso agli utenti autenticati o ai soli scopi funzionali, in linea con la categoria OWASP A01 (Broken Access Control).

In questo caso, si può procedere con la disattivazione del plugin REST API oppure imponendo limitazioni personalizzate con current_user_can().

Nascondere il percorso di login

La URL /wp-login.php è uno degli endpoint più bersagliati del Web. È conosciuta, prevedibile e universalmente valida per qualsiasi installazione di WordPress. Spostarla su un percorso non convenzionale riduce drasticamente il rumore di fondo degli attacchi automatizzati. Anche se non è una misura di sicurezza assoluta, migliora significativamente la resilienza passiva del sito e complica le operazioni dei criminali informatici alla ricerca di un potenziale bersaglio.

Per facilitare il riposizionamento del percorso di login, si può utilizzare il plugin chiamato WPS Hide Login.

Proteggere il cron di WordPress

Il sistema wp-cron.php è invocato a ogni visita del sito per eseguire operazioni programmate (come aggiornamenti o invii email). Tuttavia, in siti a traffico elevato o soggetti a scraping, questo comportamento può degradare le performance o causare esecuzioni anomale. Disabilitare il cron interno e sostituirlo con un job pianificato lato server consente un controllo granulare e impedisce attivazioni esterne non desiderate.

La gestione del problema prevede la modifica del contenuto di wp-config.php, specificando quanto segue:

define('DISABLE_WP_CRON', true);

L’intervento impedisce a WordPress di lanciare wp-config.php a ogni visita, eliminando i problemi di carico e rendendo l’esecuzione delle attività programmate completamente sotto controllo.

A livello di sistema, è possibile configurare un cron job come segue in modo da eseguire l’operazione ogni n minuti (in questo caso 5), senza caricate troppo WordPress:

*/5 * * * * www-data /usr/bin/php /var/www/html/wp-cron.php > /dev/null 2>&1

www-data è l’utente che esegue WordPress (può variare su altri sistemi), il secondo è il percorso che punta a PHP, il terzo è il percorso assoluto al file wp-cron.php.

Configurare correttamente le intestazioni di sicurezza

Il server Web può rafforzare la sicurezza del browser inviando intestazioni HTTP specifiche. Queste direttive informano il browser su come gestire i contenuti, impedendo alcune categorie di attacchi client-side, come lo sniffing del tipo MIME, l’inserimento di iframe malevoli (clickjacking) o exploit di vulnerabilità XSS. Sono facili da implementare su Nginx e migliorano la sicurezza complessiva in modo sostanziale.

Il consiglio è quello di aprire il file nginx.conf e specificare le seguenti direttive:

add_header X-Content-Type-Options nosniff;
add_header X-Frame-Options SAMEORIGIN;
add_header X-XSS-Protection "1; mode=block";

Applicazione di una Content Security Policy (CSP)

Una Content Security Policy (CSP) permette di dichiarare esattamente quali origini sono autorizzate a caricare script, immagini, fogli di stile e altri contenuti. È uno degli strumenti più efficaci per prevenire attacchi XSS persistenti, injection di JavaScript da terze parti e tracciamenti nascosti. Anche se richiede test e personalizzazione, una CSP ben scritta riduce in modo significativo i rischi legati a contenuti non affidabili.

La soluzione può essere la seguente:

add_header Content-Security-Policy "default-src 'self'; img-src 'self'; script-src 'self'; style-src 'self';";

L’istruzione va inserita all’interno del blocco server o location del file di configurazione di Nginx, tipicamente nella configurazione del virtual host.

Esaminare nel dettaglio la struttura dei temi e dei plugin personalizzati

Molti siti WordPress usano temi e plugin sviluppati in-house o da freelance, che possono contenere codice non sicuro per ignoranza, negligenza o addirittura intento malevolo. Funzioni pericolose come eval(), base64_decode(), exec() o accessi diretti a database senza sanitizzazione sono segnali di rischio. Una revisione periodica con strumenti statici (come PHP_CodeSniffer) e l’adozione di standard di codifica robusti è essenziale per evitare injection e RCE (Remote Code Execution), come previsto da OWASP A03.

Conclusioni

La sicurezza di WordPress non può essere affidata unicamente a plugin o configurazioni di base: richiede un approccio proattivo, consapevole e multilivello. Applicare i principi dell’OWASP Top 10 in un contesto LEMP significa intervenire sia a livello di codice che di infrastruttura, riducendo la superficie d’attacco e aumentando la robustezza della piattaforma.

Ogni accorgimento descritto in questa guida – dal rafforzamento della login fino alla configurazione avanzata di Nginx e delle policy HTTP – contribuisce a costruire un ecosistema più sicuro, stabile e conforme con le best practice.