Hardening WordPress: le misure di sicurezza che applichiamo

WordPress è il CMS più diffuso al mondo. Bellezza per chi lo usa, problema per la sicurezza: è anche il più attaccato. La buona notizia: la maggior parte degli attacchi sfrutta una manciata di vulnerabilità classiche. Bloccarle è semplice — basta non lasciarle aperte. Ecco le 10 misure che applichiamo automaticamente.

1. xmlrpc.php bloccato

xmlrpc.php è l’endpoint XML-RPC di WordPress, usato storicamente da app mobile vintage e ping di trackback. Oggi è la porta di ingresso #1 per attacchi brute-force sui WordPress. Il 99% dei siti non lo usa.

Cosa facciamo: .htaccess blocca direttamente le richieste a xmlrpc.php a livello server, prima ancora che WordPress veda la richiesta.

2. wp-config.php protetto

wp-config.php contiene le credenziali database del sito. Deve avere permessi 0440 (lettura per owner + gruppo, niente altro) e non essere accessibile via HTTP.

Cosa facciamo: regola in .htaccess che blocca qualsiasi richiesta diretta al file. Permessi file impostati correttamente al setup.

3. wp-admin protetto da rate-limit

Gli attacchi brute-force tentano migliaia di login al secondo. Il rate-limit blocca un IP dopo N tentativi falliti in M minuti.

Cosa facciamo: limit 5 tentativi failed login / 15 minuti per IP. Dopo viene bloccato per 1 ora. Niente plugin: lo fa il server con fail2ban (più affidabile e meno memory hog).

4. Header di sicurezza HTTP

Header che il browser usa per ridurre la superficie di attacco di XSS, clickjacking, MIME sniffing:

Cosa facciamo: tutti questi sono impostati a livello server. Funzionano subito senza modifiche al tema.

5. SSL forzato (HTTPS only)

Le richieste HTTP vengono automaticamente redirette a HTTPS via .htaccess. Il certificato Let’s Encrypt si rinnova automaticamente ogni 60 giorni.

6. wp-includes e wp-content/uploads bloccati per file PHP

I file PHP in wp-includes/ non devono essere eseguiti direttamente. Lo stesso per file PHP caricati in wp-content/uploads/ (un classico vettore: attaccante carica un PHP-shell mascherato da immagine).

Cosa facciamo: regola .htaccess che blocca l’esecuzione PHP in queste directory. Le immagini reali continuano a caricarsi normalmente — non c’è impatto sul frontend.

7. Database prefisso non default

Le tabelle WordPress di default iniziano con wp_. Cambiarlo in qualcosa di random (es. hwx7k_) blocca attacchi SQL automatici che cercano specificamente wp_users, wp_options.

Cosa facciamo: nuovi siti installati via dashboard partono con prefisso random. Sui siti migrati esistenti, lo cambiamo durante la migrazione (con WP search-replace automatico). Su richiesta possiamo rifarlo anche dopo.

8. Username “admin” e “administrator” rifiutati

I bot brute-force partono sempre da questi due username. Toolkit Pro durante l’installazione rifiuta di creare un account admin con questi nomi e suggerisce alternative.

9. Auto-update di sicurezza

WordPress ha auto-update di sicurezza dal 2013, ma molti hosting li disattivano “per stabilità”. Da noi sono attivi:

• Patch sicurezza WordPress core — applicate entro 24h dal rilascio ufficiale
• Patch sicurezza plugin/temi — applicate solo dopo che la AI di monitoring le ha verificate su un canary site (24h di test); sui piani Pro+ puoi anche disabilitarle e gestirle a mano

10. Audit log di tutte le modifiche AI

Ogni azione che l’AI Assistant esegue sul tuo sito (modifica plugin, fix snippet, applicazione hardening) viene tracciata in un audit log consultabile dalla dashboard. Vedi chi ha fatto cosa quando per 90 giorni.

Cosa non facciamo (intenzionalmente)

• Niente firewall applicativo che richiede whitelist manuali — generano falsi positivi che bloccano admin legittimi
• Niente “scansione malware” giornaliera CPU-pesante — l’analisi sicurezza è on-demand quando lo chiedi all’AI Assistant
• Niente IP geo-blocking di default — il tuo sito deve essere raggiungibile globalmente salvo tue richieste specifiche

Vedi anche

• Hostwebo Toolkit Pro
• Backup e ripristino
• AI per diagnostica sicurezza