Security Pilot

Security Pilot è un plugin di sicurezza completo per WordPress, che mette in difesa il sito da attacchi e vulnerabilità comuni. Applica gli header HTTP di sicurezza standard del settore, protegge la pagina di login dagli attacchi brute-force, blocca le richieste malevole con un firewall integrato, restringe gli endpoint sensibili della REST API e include un audit one-click che valuta l’installazione dalla A alla F.

A differenza delle security suite onnicomprensive, Security Pilot è leggero e modulare: abiliti solo le protezioni che ti servono. Ogni modulo è togglabile in modo indipendente e tutte le impostazioni si gestiscono dal menu top-level Security Pilot nella sidebar admin di WordPress.

Punti di forza

• Header HTTP di sicurezza — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection e rimozione dell’header X-Powered-By.
• Protezione del login — rate limiting configurabile, lockout temporanei e ban permanenti per i recidivi, con alert via email opzionali.
• Firewall delle richieste — rilevamento pattern-based di SQL injection, cross-site scripting (XSS), path traversal, remote file inclusion (RFI) e command injection.
• Protezione REST API — blocca l’accesso non autorizzato a gruppi di endpoint sensibili come /wp/v2/users, WooCommerce, Jetpack, wp-site-health, Divi Builder ed Elementor.
• Hardening di WordPress — disabilita il file editor e XML-RPC, sopprime pingback e trackback, nasconde la versione di WordPress, rimuove il link RSD e il manifest Windows Live Writer.
• Rate limiter — throttling per IP contro flood di 404 e altri pattern ad alta frequenza, con max-block count e finestra rolling configurabili.
• Protezione dei form — rate-limit sulle submission frontend, blocco di domini email usa-e-getta e trappole bot tramite honeypot nascosti e check di time-to-fill configurabile.
• Security Check — audit one-click che valuta l’installazione dalla A alla F e riporta lo stato per check (PASS / WARNING / FAIL) su hardening, esposizione della REST API, plugin/temi obsoleti, impostazioni di debug, file editor e molto altro.
• Access Rules & attack logging — gestisci IP bloccati, IP in whitelist e URL in whitelist da una schermata a tre tab, e approfondisci ogni richiesta bloccata nell’Attack Log.

Requisiti

Security Pilot è pensato per i siti WordPress moderni self-hosted.

• Un’installazione WordPress funzionante con accesso amministratore.
• Una versione di PHP supportata dalla tua release WordPress.
• HTTPS fortemente consigliato. L’header HSTS andrebbe abilitato solo quando il sito è raggiungibile via TLS su ogni URL, sottodomini inclusi.
• Permessi sufficienti per modificare gli header HTTP di risposta. Sulla maggior parte degli hosting managed funziona out of the box; davanti ad alcuni reverse proxy o CDN gli header vanno lasciati passare all’edge.

Non ci sono servizi esterni da configurare e non servono API key. Impostazioni, log e blocklist sono memorizzati nel tuo database WordPress.

Installazione

1. Scarica il file ZIP di Security Pilot.
2. In WordPress apri Plugin → Aggiungi nuovo → Carica plugin.
3. Scegli il file ZIP e seleziona Installa ora.
4. Clicca Attiva plugin al termine dell’upload.
5. Apri Security Pilot → Impostazioni per esaminare i moduli. Le quattro voci di sottomenu, nell’ordine in cui appaiono, sono Security Check, Access Rules, Attack Log e Impostazioni.

Dopo l’attivazione nessuna protezione è forzatamente attiva — ogni modulo parte in uno stato noto e si può togglare singolarmente. Questo rende sicuro installare il plugin in produzione e introdurre l’hardening a piccoli passi reversibili.

Configurazione

Tutta la configurazione si fa da Security Pilot → Impostazioni. La pagina raggruppa le impostazioni in moduli — ogni modulo è una card collassabile con il proprio toggle di attivazione e un piccolo numero di opzioni.

Una card Licenza in cima accetta una chiave PILOT-XXXX-XXXX-XXXX-XXXX (dall’email di conferma ordine) e abilita gli aggiornamenti automatici del plugin dal feed di rilascio GitHub quando verificata. Il plugin funziona pienamente anche senza chiave; solo il canale di auto-update è gated.

Header HTTP di sicurezza

Il modulo header aggiunge a ogni risposta servita da WordPress gli header HTTP di sicurezza basati sugli standard. Attiva o disattiva i singoli header secondo le esigenze del tuo sito.

Alcune note quando configuri gli header:

• HSTS, una volta ricevuto dai browser, è permanente. Verifica che HTTPS funzioni ovunque — incluso www e i sottodomini che vuoi coprire — prima di abilitarlo.
• La Content-Security-Policy è l’header più potente e più invasivo. Parti dai default report-friendly, poi stringi la policy dopo aver controllato la console del browser per eventuali risorse bloccate sulle tue pagine reali.
• Se il sito sta dietro una CDN o un reverse proxy che riscrive gli header, assicurati che quegli edge facciano passare invariati i valori aggiunti da Security Pilot.

Protezione del login

La Protezione login conta i tentativi di autenticazione falliti per indirizzo IP e applica un lockout una volta raggiunta una soglia. Dopo un numero configurabile di lockout, l’IP può essere bannato permanentemente.

Impostazioni disponibili:

• Max tentativi falliti — numero di login falliti da un IP prima di scatenare un lockout. Accetta valori da 1 a 20. Il default di 5 è un buon punto di partenza.
• Finestra dei tentativi — finestra temporale rolling, in minuti, su cui contare i fallimenti. Accetta valori da 1 a 120.
• Durata del lockout — per quanti minuti l’IP bloccato resta tale. Accetta valori da 1 a 1440 (24 ore).
• Soglia di ban permanente — numero di lockout distinti che un IP può accumulare prima di essere bannato definitivamente. Accetta valori da 1 a 20.
• Alert email — quando abilitati, l’amministratore del sito riceve un’email a ogni attacco rilevato e a ogni nuovo IP aggiunto alla blocklist.
• Nascondi messaggi d’errore dettagliati — messaggi d’errore generici (“credenziali non valide”) sostituiscono quelli di default di WordPress, impedendo agli attaccanti di capire se uno username esiste.

La protezione si applica sia a wp-login.php sia all’endpoint di autenticazione XML-RPC standard, quando XML-RPC è ancora attivo.

Firewall delle richieste

Il Firewall delle richieste ispeziona le richieste in arrivo cercando pattern malevoli e risponde con 403 Forbidden quando ne trova uno. I pattern di rilevamento sono built-in e coprono:

• SQL injection — payload comuni contro query parameter, body POST e cookie.
• Cross-site scripting (XSS) — signature di attacchi riflessi e stored.
• Path traversal — tentativi tipo ../ per uscire dal document root.
• Remote file inclusion (RFI) — riferimenti a URL esterni in contesti che si aspettano path locali.
• Command injection — metacaratteri di shell in parametri che possono finire in funzioni tipo system.

Il firewall non ha configurazione per-rule. È solo on o off. Le richieste bloccate vengono registrate nell’attack log descritto sotto, incluso il parametro offensivo e la regola che ha scatenato il blocco.

Rate Limiter (protezione contro flood di 404)

I siti sotto probe brute-force generano centinaia di 404 per IP al minuto, cercando asset di plugin nascosti o backup di wp-config. Il Rate Limiter mette un tetto a quel traffico per IP sorgente tracciando gli hit 404 in una finestra rolling:

Il blocco è enforce con lo stesso meccanismo usato dalla Protezione login, quindi compare nella tab Access Rules → Blocked IPs con reason 404_flood.

Protezione REST API

WordPress espone di default una REST API ampia, inclusi endpoint utili ai site builder ma spesso superflui in produzione. Security Pilot può bloccare l’accesso non autenticato a interi gruppi di endpoint lasciando il resto dell’API intatto.

Gruppi protetti:

• /wp/v2/users — enumerazione utenti via endpoint core users.
• WooCommerce — endpoint store, ordini e clienti esposti da WooCommerce quando è installato.
• Jetpack — namespace REST di Jetpack.
• wp-site-health — endpoint di health-check che possono rivelare info sull’ambiente.
• Divi Builder — endpoint REST di Divi.
• Elementor — endpoint REST di Elementor.

Abilita la protezione solo per i gruppi che non ti servono. Per esempio, un sito che non gira WooCommerce può tranquillamente blindare gli endpoint WooCommerce. Il plugin verifica l’autenticazione su ogni richiesta e restituisce un errore di autorizzazione ai chiamanti non autenticati che provano ad accedere a un gruppo protetto.

Protezione dei form

Protegge form di contatto / commento / login del sito da spam, registrazioni con email usa-e-getta e submission bot ad alta velocità:

Trappole honeypot (campi nascosti compilati solo dai bot) e un check di tempo minimo di compilazione girano insieme ai gate di rate. I tentativi bloccati finiscono nell’Attack Log.

Hardening di WordPress

Il modulo hardening spegne feature di WordPress spesso abusate o che divulgano info utili a pianificare un exploit. Ogni opzione è indipendente.

• Disabilita file editor — spegne l’editor di file di tema e plugin dentro la dashboard (DISALLOW_FILE_EDIT). Un attaccante che riesca a procurarsi credenziali admin non può più modificare codice direttamente dall’UI di WordPress.
• Disabilita XML-RPC — blocca l’endpoint xmlrpc.php, bersaglio comune di brute-force e amplification. Disabilitalo solo se nessuna integrazione del tuo sito si appoggia su di esso.
• Disabilita pingback e trackback — chiude un vettore di amplification storico, usato in campagne DDoS.
• Nascondi versione WordPress — rimuove il meta tag generator e i query parameter di versione dagli asset enqueue, così la versione installata non finisce nel sorgente.
• Rimuovi link RSD — toglie il link Really Simple Discovery usato dai client di publishing esterni.
• Rimuovi manifest WLW — rimuove il link al manifest di Windows Live Writer, raramente utile oggi.

Sulla maggior parte dei siti in produzione è sicuro abilitare tutte le opzioni di hardening. Disabilitare file editor e XML-RPC in particolare è considerato una baseline dalla comunità di sicurezza WordPress.

Security Check

La pagina Security Check — Security Pilot → Security Check — esegue un audit one-click e produce un voto da A (“ottimo, la tua sicurezza è solida”) fino a F, insieme a contatori KPI per passed, failed, warning e total checks.

Il Check copre ogni categoria che il plugin può verificare da dentro WordPress, tra cui:

• HTTPS configurato per la site URL.
• File editor disabilitato (DISALLOW_FILE_EDIT).
• XML-RPC disabilitato.
• Debug log e debug display spenti in produzione.
• Accesso a wp-config.php bloccato a livello web server.
• Core WordPress, plugin e temi aggiornati.
• Plugin inattivi ancora installati (superficie d’attacco).
• Username admin di default assente.
• Protezione REST API abilitata.
• Header HTTP di sicurezza, protezione login e firewall delle richieste attivi.
• DB prefix forte, esposizione PHP, server signature.

Ogni riga stampa un titolo breve, una descrizione di una riga e un badge di stato (PASS, WARNING, FAIL, INFO). Il modulo Impostazioni → Security Check espone tre toggle opt-in che aggiungono check più profondi (plugin obsoleti, temi obsoleti, lookup di vulnerabilità dei plugin contro un feed pubblico) — questi girano quando si richiede il report e lo rallentano di qualche secondo, quindi sono off per default. Dal report stesso, i fix sono di solito a un click dentro l’admin WordPress (aggiorna plugin, elimina plugin inattivo, sposta un toggle di hardening).

Utilizzo

Una prima passata pratica sul plugin si fa così.

1. Installa e attiva Security Pilot.
2. Apri Security Pilot → Impostazioni.
3. Abilita Header HTTP di sicurezza con i default consigliati. Visita qualche pagina del sito e controlla la console del browser per eventuali violazioni Content-Security-Policy inattese.
4. Abilita Protezione login. Lascia Max tentativi falliti a 5, scegli una finestra di 15 minuti e un lockout di 60 minuti per un sito tipico. Attiva gli alert email così scopri subito quando il sito viene attaccato.
5. Abilita il Firewall delle richieste. Non serve altra configurazione.
6. Abilita il Rate Limiter per intercettare flood di 404 (default 25 hit in 60 secondi → IP aggiunto alla blocklist).
7. Attiva la Protezione REST API per i gruppi di endpoint che il tuo sito non usa pubblicamente. Il gruppo /wp/v2/users è quasi sempre sicuro da blindare.
8. Abilita la Protezione dei form sui siti con form di contatto / commento — scegli un cooldown per IP sensato e una blocklist di TLD.
9. Abilita le opzioni di Hardening WordPress. Come minimo disabilita file editor e XML-RPC sui siti in produzione.
10. Lancia un Security Check e agisci su ogni riga WARNING e FAIL (aggiorna o elimina i plugin/temi elencati, sposta i toggle di hardening segnalati).

Dopo questa prima passata, torna periodicamente su Security Pilot → Security Check per tenere il voto sopra C, e su Attack Log + Access Rules per rivedere quello che è stato catturato.

Rivedere le access rules

La schermata Access Rules (Security Pilot → Access Rules) è un pannello centralizzato a tre tab per blocklist e whitelist basate su IP e URL:

• Blocked IPs — ogni indirizzo attualmente bloccato dalla Protezione login, dal Rate Limiter o dal firewall. Ogni riga stampa l’IP, il motivo del blocco (es. firewall:path_traversal, 404_flood, firewall:sqli), l’ora dell’aggiunta e un pulsante Sblocca. Un form in alto ti permette di bloccare manualmente un IP arbitrario con motivo opzionale, e un campo di ricerca filtra per IP o motivo.
• Whitelisted IPs — indirizzi esentati da ogni check (ufficio, servizio di monitoring, server di staging, IP di casa tuo).
• Whitelisted URLs — path esentati dal Rate Limiter sui 404 (utile quando un endpoint legittimo restituisce 404 in burst per design).

Usa questa schermata per:

• Sbloccare un indirizzo finito nel limbo perché un utente legittimo ha sbagliato la password.
• Mettere in whitelist un IP noto come buono (ufficio, servizio di monitoring, server di staging) così non viene bloccato per errore.
• Mettere in whitelist un URL che colpisce il rate limit 404 per design (es. un path di probe consumato da monitoring esterno).

Rivedere l’attack log

L’Attack Log (Security Pilot → Attack Log) registra ogni richiesta bloccata, inclusi lockout brute-force, hit del firewall, scatti del rate-limiter, rimbalzi di form-spam e rifiuti REST API. Ogni riga porta timestamp, IP sorgente, Attack type (es. RESTRICTION, REQUEST_URI, PATH_TRAVERSAL, COMMAND_INJECTION, POST_X), il Rule listener che ha emesso il blocco e il Request URI che l’ha triggerato. Un’azione bulk Clear Log azzera la pagina e la toolbar espone una ricerca testuale più filtri per IP e per listener.

Il log serve sia per la review post-incident sia per tunare il firewall: se una richiesta legittima al tuo sito compare nel log, puoi identificare quale regola ne è responsabile e decidere se mettere in whitelist la richiesta, l’IP o raffinare la regola.

Widget nella dashboard di WordPress

Security Pilot aggiunge un widget alla Dashboard standard (la pagina che WordPress apre al login), così i numeri principali sono visibili dal momento in cui entri.

Il widget mostra:

• L’ultimo voto del Security Check (A–F) e lo score numerico (es. A 95/100), reso come anello colorato.
• Un contatore live Blocked IPs preso dalla tabella Access Rules.
• Un contatore corrente Attacks preso dall’Attack Log.
• L’elenco Recent Attacks — ultime cinque righe dell’Attack Log con badge di tipo, IP sorgente e timestamp.
• Shortcut nel footer verso Attack Log e Full Security Report.

FAQ

Security Pilot sostituisce altri plugin di sicurezza?

Per la maggior parte dei siti, sì. Security Pilot copre header HTTP, protezione login, filtering delle richieste, restrizioni REST API, hardening e audit. È volutamente leggero invece che una suite onnicomprensiva. Farlo girare insieme a un altro firewall o plugin di protezione login è tecnicamente possibile ma raramente utile e può portare a regole sovrapposte che scattano due volte.

Gli header rompono il sito?

I valori di default sono conservativi. I due header che richiedono più attenzione sono HSTS e Content-Security-Policy.

• Abilita HSTS solo dopo che il sito è completamente raggiungibile in HTTPS, sottodomini inclusi che vuoi coprire. L’header viene messo in cache dai browser e non si può revocare facilmente.
• Tara la Content-Security-Policy guardando la console del browser per le risorse bloccate sulle pagine reali. Spesso script custom, font e analytics vanno aggiunti alla policy.

Il firewall blocca traffico legittimo?

I pattern di rilevamento puntano a signature di attacchi noti e tendono a essere specifici. Se una richiesta legittima viene bloccata, comparirà nell’attack log con la regola che ha scatenato il blocco. Puoi sbloccare l’IP e, se il pattern è davvero inevitabile, documentare l’eccezione per il tuo team.

Il plugin funziona dietro una CDN o un reverse proxy?

Sì. Il plugin legge l’IP di origine dagli header di richiesta standard e identifica correttamente i visitatori dietro CDN, a patto che il tuo hosting inoltri l’header X-Forwarded-For (o equivalente) corretto. Assicurati che nessun layer all’edge davanti a WordPress rimuova gli header di risposta aggiunti da Security Pilot.

Posso esportare attack log o liste di IP bloccati?

Attack log e tabella degli IP bloccati sono memorizzati nel database WordPress e si revisionano direttamente dall’interfaccia admin. Per archiviazione long-term o analisi off-site, fai un backup del database come faresti per qualsiasi altro dato WordPress.

Disabilitare XML-RPC rompe qualcosa?

XML-RPC è usato dal client legacy Windows Live Writer, dalle app mobile WordPress in certe configurazioni e da un piccolo numero di integrazioni di terze parti. Se non usi nessuno di questi, disabilitare XML-RPC è uno degli step di hardening one-click più efficaci che puoi fare.

Le impostazioni si conservano quando il plugin viene disattivato?

Sì. Disattivare Security Pilot mantiene la tua configurazione, l’attack log e la blocklist nel database, così riattivare il plugin ripristina lo stato precedente.

Troubleshooting

Un utente legittimo è bloccato fuori

Apri Blocked IPs, individua la entry per l’indirizzo coinvolto e rimuovi il blocco. Se lo stesso utente viene bloccato ripetutamente, valuta:

• Aumentare Max tentativi falliti per gli utenti smemorati.
• Aggiungere l’IP dell’utente (o il NAT dell’ufficio) alla allowlist.
• Chiedere all’utente di resettare la password invece di tirare a indovinare.

Il browser blocca risorse dopo aver abilitato CSP

La Content-Security-Policy è volutamente stretta di default. Apri i developer tools del browser e guarda la tab Console — il browser segnala ogni risorsa bloccata insieme alla direttiva che l’ha rifiutata. Aggiusta la CSP per includere le origin fidate (CDN, provider di analytics, host di font) su cui il tuo sito si appoggia.

Le pagine continuano a caricare in HTTP dopo aver abilitato HSTS

HSTS viene rispettato solo dopo che il browser ha visto l’header almeno una volta su HTTPS. Visita il sito direttamente su https:// per innescare la cache. Se il sito non è ancora raggiungibile via HTTPS per ogni URL che pubblicizzi, disabilita HSTS finché la migrazione non è completa.

Le integrazioni REST API smettono di funzionare

Se un’integrazione che si appoggia a un gruppo di endpoint protetti smette di funzionare, disabilita temporaneamente la protezione per quel gruppo sotto Protezione REST API e conferma che l’integrazione si autentichi correttamente. Molte integrazioni si aspettano di essere chiamate come utente WordPress autenticato; le richieste autenticate non sono bloccate da questo modulo.

Gli header non sono presenti nella risposta

Alcuni host o reverse proxy rimuovono o sovrascrivono gli header di risposta aggiunti da PHP. Verifica gli header con uno strumento come curl -I https://example.com/ o con il network inspector del browser. Se un header manca, controlla la documentazione dell’host su come far passare header custom, o aggiungi l’header all’edge se l’host lo richiede.

Gli alert email non arrivano

Gli alert email usano la funzione wp_mail() di WordPress. Se non arriva nessuna email, il problema è quasi sempre della configurazione mail del sito, non di Security Pilot. Installa un plugin di mail transazionale (per esempio uno che indirizza la mail WordPress via SMTP) e ritesta triggerando un lockout da un browser di test.