Sicurezza WordPress per Agenzie: Hardening Avanzato per Siti Client [2026]

Nel 2024, WPScan ha catalogato oltre 13.000 vulnerabilità nell’ecosistema WordPress. Tredici mila. Se gestisci un’agenzia con 20, 30 o 50 siti cliente, quel numero non è una statistica astratta: è la probabilità concreta che uno dei tuoi siti venga compromesso entro i prossimi dodici mesi. La sicurezza WordPress agenzie non è un’opzione o un “nice-to-have” da aggiungere al preventivo. È il fondamento su cui poggia tutta la tua reputazione professionale.

Il problema è che la maggior parte delle agenzie gestisce la sicurezza in modo reattivo: si interviene dopo la compromissione, non prima. In questa guida analizziamo un approccio sistematico all’hardening WordPress pensato specificamente per chi gestisce portfolio di siti cliente, con configurazioni concrete, codice reale e strumenti testati in produzione.

Il rischio reale — perché le agenzie sono bersagli privilegiati

Un freelance con tre siti WordPress ha un rischio circoscritto. Un’agenzia che gestisce 30 siti cliente ha un profilo di rischio completamente diverso. Nella nostra esperienza, il vettore di attacco più sottovalutato non è il singolo sito vulnerabile, ma la connessione laterale tra i siti di una stessa agenzia.

Scenario tipico: un plugin obsoleto su un sito piccolo (magari il sito da 200€/anno di un cliente storico che “non ha bisogno di aggiornamenti”) viene compromesso. L’attaccante trova le credenziali FTP nel wp-config.php, che sono le stesse usate su altri tre siti. Nel giro di 48 ore, quattro siti sono infetti. Se usi un pannello di gestione centralizzato con le stesse credenziali API per tutti, la situazione può degenerare ulteriormente.

Questo è il motivo per cui la protezione siti WordPress per le agenzie richiede un approccio diverso rispetto alla singola installazione.

Vettori di attacco più comuni nel portfolio di un’agenzia

La fonte di riferimento per capire la superficie di attacco di WordPress è la documentazione ufficiale sulla sicurezza di WordPress.org, aggiornata regolarmente dal team core. Per il quadro generale delle vulnerabilità web, il riferimento è l’OWASP Top Ten.

Hardening delle credenziali a livello di agenzia

Il primo livello di sicurezza WordPress agenzie è banale ma spesso ignorato: le credenziali. Non parliamo di password “sicure” nel senso comune (maiuscole, numeri, simboli). Parliamo di una policy strutturata che copre tutti i siti del portfolio.

Password policy minima per un’agenzia professionale

• Lunghezza minima: 20 caratteri. Non 8, non 12. Venti. Un brute-force su una password di 20 caratteri casuali è computazionalmente irrealizzabile con hardware attuale.
• Rotazione ogni 90 giorni per tutti gli account admin, inclusi i tuoi collaboratori.
• Nessuna password condivisa tra siti. Ogni sito deve avere credenziali uniche. Sembra ovvio, ma nella pratica il 60-70% delle agenzie che seguiamo usa la stessa password admin su tutti i siti di un cliente.
• Application password separate per le integrazioni API: non usare mai le credenziali principali per connettori esterni.

Gestori di password consigliati

Abbiamo testato diversi password manager in contesti di agenzia. Le due opzioni che consigliamo:

• Bitwarden self-hosted: open source, deployment su VPS proprietario, GDPR-compliant, costo zero per l’hosting se hai già un server. Ideale per agenzie che gestiscono dati di clienti in settori regolamentati.
• 1Password Teams: interfaccia più curata, vaulting per cliente, integrazione con strumenti come GitHub e Slack. A pagamento (~4$/utente/mese), ma il ROI è immediato se consideri il costo di una singola violazione.

Disabilitare l’enumerazione degli utenti

WordPress espone di default i nomi utente tramite le URL degli autori (/?author=1). Un attaccante può facilmente raccogliere tutti gli username validi e usarli in un attacco a dizionario. Questo snippet va nel functions.php del tema o, meglio, in un plugin mu (must-use):

// Blocca enumerazione utenti tramite redirect URL autore
add_action('template_redirect', function() {
    if (is_author() && !is_user_logged_in()) {
        wp_redirect(home_url(), 301);
        exit;
    }
});

Aggiungilo a tutti i siti del portfolio tramite un mu-plugin distribuito via Composer o tramite il tuo tool di gestione centralizzata.

Hardening del file system

I permessi file errati sono uno dei vettori più sfruttati dopo una compromissione iniziale. Anche se l’attaccante entra tramite un plugin vulnerabile, permessi corretti limitano drasticamente il danno che può fare.

Permessi corretti per un’installazione WordPress

• Cartelle: 755 (rwxr-xr-x) — il web server può leggere ed eseguire, solo il proprietario può scrivere
• File: 644 (rw-r–r–) — il proprietario può scrivere, tutti possono leggere
• wp-config.php: 600 (rw——-) — solo il proprietario può leggere e scrivere. Mai 777, mai 666.

Per normalizzare i permessi su un intero sito via SSH:

find /path/to/wordpress -type d -exec chmod 755 {} \;
find /path/to/wordpress -type f -exec chmod 644 {} \;
chmod 600 /path/to/wordpress/wp-config.php

Bloccare file sensibili via .htaccess

Disabilitare la modifica file dall’admin

Se un attaccante accede all’area admin, la prima cosa che cerca è l’editor di temi e plugin. Due costanti in wp-config.php bloccano questa possibilità:

// Disabilita editor temi e plugin nell'admin
define('DISALLOW_FILE_EDIT', true);

// Disabilita anche installazione/aggiornamento plugin e temi dall'admin
define('DISALLOW_FILE_MODS', true);

Nota pratica: DISALLOW_FILE_MODS blocca anche gli aggiornamenti automatici dall’admin. Se usi questa costante, gli aggiornamenti devono passare necessariamente da WP-CLI o dal tuo sistema di deployment. Per una automazione della gestione WordPress matura, questa è la configurazione corretta.

Autenticazione a due fattori (2FA) su tutti i siti client

L’autenticazione due fattori WordPress è la misura singola con il miglior rapporto sforzo/impatto nella sicurezza WordPress agenzie. Una password rubata diventa inutile senza il secondo fattore. Eppure la maggior parte dei siti che riceviamo in gestione non ha il 2FA abilitato su nessun account admin.

Plugin consigliati per il 2FA

• WP 2FA (gratuito): interfaccia setup guidata per gli utenti, supporta TOTP (Google Authenticator, Authy), email OTP, e backup codes. Funziona bene per clienti non tecnici.
• Wordfence Login Security: parte della suite Wordfence, integra 2FA con le altre funzionalità di protezione. Ottimo se già usi Wordfence come plugin sicurezza WordPress principale.

Abilitare 2FA in batch su tutti i siti con WP-CLI

Se gestisci molti siti, configurare il 2FA manualmente su ognuno è impraticabile. Questo snippet WP-CLI forza il 2FA per tutti gli utenti con ruolo administrator:

#!/bin/bash
# Abilita 2FA obbligatorio per tutti gli admin su una lista di siti
# Richiede WP 2FA installato e attivato

SITES=(
    "/var/www/cliente1"
    "/var/www/cliente2"
    "/var/www/cliente3"
)

for SITE in "${SITES[@]}"; do
    echo "Configurando 2FA per: $SITE"
    wp --path="$SITE" option update wp2fa_settings \
        '{"enforcement_policy":"all-users","grace_period":"0"}' \
        --format=json
    echo "Done: $SITE"
done

Limitare i tentativi di login

Senza rate limiting, wp-login.php è vulnerabile al brute force. Le opzioni:

• Wordfence: blocca automaticamente IP dopo N tentativi falliti, configurabile per soglia e durata blocco
• Cloudflare Rate Limiting: blocca a livello CDN prima che il traffico raggiunga il server (più efficiente)
• .htaccess: whitelist IP per wp-admin se i tuoi collaboratori hanno IP statici

Web Application Firewall (WAF) per portfolio multi-sito

Il firewall WordPress è il layer che filtra le richieste malevole prima che raggiungano il codice. Per le agenzie, la scelta del WAF ha implicazioni sia tecniche che economiche: deve scalare su decine di siti senza diventare un costo proibitivo.

Confronto Wordfence vs Sucuri vs Cloudflare WAF

Il setup che abbiamo adottato per la maggior parte dei siti cliente: Cloudflare WAF (gratuito) + Wordfence Free. Cloudflare blocca il traffico malevolo a livello CDN, riducendo il carico sul server. Wordfence gestisce la protezione a livello applicativo e fornisce il vulnerability scanner. Per approfondire le regole WAF di Wordfence, la loro sezione Learn è una delle risorse tecniche più complete disponibili gratuitamente.

Regola Cloudflare per bloccare wp-login.php da paesi non necessari

Se i tuoi clienti sono tutti italiani e non hai mai bisogno di accedere da fuori Europa, puoi bloccare wp-login.php per qualsiasi richiesta proveniente da paesi che non utilizzi mai. Dal pannello Cloudflare > Security > WAF > Custom Rules:

(http.request.uri.path contains "/wp-login.php" 
  and not ip.geoip.country in {"IT" "DE" "FR" "ES" "GB"})
→ Block

Questa singola regola elimina la stragrande maggioranza dei tentativi di brute force, che provengono prevalentemente da bot in Asia, America Latina e Africa orientale.

Monitoraggio sicurezza con AgencyPilot

Le misure di hardening che abbiamo descritto riducono drasticamente la superficie di attacco. Ma il monitoraggio continuo è quello che ti permette di rilevare le anomalie che sfuggono alle difese statiche.

In AgencyPilot abbiamo integrato il security scanning direttamente nel workflow di monitoraggio WordPress per agenzie. Il sistema controlla automaticamente:

• Versioni plugin e temi rispetto al database delle CVE note: se un plugin installato su 15 dei tuoi siti ha una vulnerabilità critica, ricevi un alert immediato su tutti i siti interessati, non uno per uno.
• Integrità dei file core: confronto con i checksum ufficiali di WordPress.org. Se un file core viene modificato, l’alert arriva in minuti, non giorni.
• Anomalie di login: picchi di tentativi falliti, login da IP mai visti, accessi in orari anomali.
• Uptime e status HTTP: un sito che restituisce 500 o viene defacciato viene rilevato entro 60 secondi.

La differenza rispetto a controllare manualmente o ricevere le notifiche singole da ogni Wordfence installato è sostanziale: invece di 50 email da 50 siti, hai una dashboard unificata che mostra lo stato di sicurezza del tuo intero portfolio e una prioritizzazione degli interventi.

Una solida strategia di backup WordPress integrata con il monitoraggio completa il quadro: se il worst case si verifica, hai i backup recenti e verificati pronti per il ripristino.

Aggiornamenti sicuri senza rompere i siti client

Gli aggiornamenti sono il principale vettore di riduzione del rischio, ma anche la principale causa di downtime non pianificato nelle agenzie. Il problema non è aggiornare: è aggiornare senza un processo.

La strategia staging → test → produzione

1. Crea un ambiente di staging per ogni sito cliente importante. Può essere un sottodominio (staging.cliente.it) o un clone locale.
2. Applica gli aggiornamenti sullo staging e verifica che il sito funzioni: homepage, form di contatto, WooCommerce checkout se presente, integrazioni terze.
3. Solo dopo la verifica, applica in produzione, possibilmente fuori dall’orario di picco del sito.
4. Snapshot pre-aggiornamento: prima di ogni update in produzione, crea uno snapshot del database e dei file. Se qualcosa va storto, il rollback è questione di minuti.

Cosa automatizzare e cosa no

Abbiamo implementato una distinzione netta: gli aggiornamenti di sicurezza critici (CVSS ≥ 9.0) vengono applicati automaticamente su tutti i siti, senza aspettare l’approvazione manuale. Per tutti gli altri aggiornamenti — major release, feature update, aggiornamenti di temi — il processo rimane manuale con staging obbligatorio.

Questa distinzione riduce il rischio di zero-day sfruttabili senza introdurre instabilità nei siti. Per una guida completa alla gestione scalabile, vedi la nostra sezione sull’automazione della gestione WordPress.

Per configurare gli aggiornamenti automatici solo per le security release in wp-config.php:

// Aggiornamenti automatici solo per release sicurezza WordPress core
define('WP_AUTO_UPDATE_CORE', 'minor');

// Aggiornamenti automatici plugin: solo patch di sicurezza
// (richiede filtro specifico - da aggiungere in mu-plugin)
add_filter('auto_update_plugin', function($update, $item) {
    // Lista plugin critici da aggiornare sempre automaticamente
    $critical = ['wordfence', 'woocommerce', 'contact-form-7'];
    if (in_array($item->slug, $critical)) {
        return true;
    }
    return false;
}, 10, 2);

FAQ — Sicurezza WordPress per Agenzie

Qual è il plugin di sicurezza WordPress migliore per un’agenzia?

Non esiste una risposta universale, ma nella nostra esperienza la combinazione più efficace per le agenzie è Wordfence Free per la protezione endpoint e il vulnerability scanner, combinato con Cloudflare WAF gratuito per il filtraggio a livello CDN. Se il budget lo consente, Wordfence Premium aggiunge le signature delle vulnerabilità in tempo reale (invece di 30 giorni di ritardo). Per siti e-commerce o con dati sensibili, considera Sucuri per la garanzia di cleanup inclusa nel piano.

Con quale frequenza fare un audit di sicurezza WordPress?

Minimo trimestrale per i siti standard, mensile per i siti e-commerce o con accesso a dati personali. Un audit minimo include: verifica permessi file, scan vulnerabilità plugin/temi, revisione utenti admin (rimuovere account non più necessari), verifica log di accesso, test del processo di ripristino backup. Il monitoraggio automatico continuo non sostituisce l’audit periodico manuale: li complementa.

È sicuro usare WordPress multisite per i siti dei clienti?

WordPress multisite è sicuro se configurato correttamente, ma introduce rischi specifici per le agenzie: un compromesso a livello di super-admin colpisce tutte le installazioni nella rete. Nella nostra esperienza, il multisite funziona bene per agenzie che gestiscono siti strutturalmente simili (stessa base di tema, stessa configurazione). Per siti con requisiti molto diversi o clienti con esigenze di isolamento elevate, installazioni separate sono più sicure e più semplici da gestire.

Come proteggere wp-admin senza plugin?

Tre misure efficaci senza plugin: 1) HTTP Basic Auth su wp-admin via .htaccess (doppio layer di autenticazione), 2) IP whitelist sullo stesso .htaccess per permettere l’accesso solo dagli IP dell’agenzia, 3) Regola Cloudflare WAF per bloccare o sfidare con CAPTCHA gli accessi a /wp-login.php e /wp-admin/ da IP non in whitelist. La combinazione di queste tre misure rende il brute force praticamente impossibile.

Cosa fare se un sito WordPress viene compromesso?

Procedura immediata: 1) Porta il sito offline (pagina di manutenzione) per prevenire danni ulteriori ai visitatori, 2) Cambia immediatamente tutte le password: DB, FTP, wp-admin, hosting panel, 3) Ripristina da un backup pre-compromissione verificato, 4) Identifica il vettore di ingresso (log server, timestamp file modificati), 5) Applica la patch prima di tornare online, 6) Notifica il cliente con un report dettagliato. Se non hai un backup pulito, usa un servizio di cleanup professionale (Sucuri o simili) piuttosto che tentare di ripulire manualmente un sito infetto.