mettere in sicurezza wp admin
Ridurre la superficie di attacco fin dalla pagina di accesso
Quando bot scansionano continuamente i siti WordPress, il punto d'ingresso più preso di mira rimane l'accesso all'amministrazione. Senza installare alcun plugin, l'obiettivo è semplice: rendere la pagina di accesso meno accessibile, limitare ciò che l'attaccante può testare (identificativi, password, endpoint) e aggiungere serrature lato server. Non si cerca di rendere WordPress invisibile, ma di aumentare il costo dell'attacco e ridurre drasticamente i tentativi automatizzati.
Prima di modificare qualsiasi cosa, partite dal presupposto che una regola errata in un file del server possa bloccare l'accesso alla dashboard. Eseguite un backup dei file, annotate le modifiche e mantenete un accesso FTP/SFTP o al gestore file del vostro hosting per tornare indietro.
Limitare l'accesso a wp-admin per IP (il metodo più efficace in ambito B2B)
Se voi (o il vostro team) vi collegate da uno o più IP fissi (uffici, VPN, IP dell'agenzia), il filtraggio per IP è uno scudo estremamente potente: anche se l'URL è nota, la richiesta viene rifiutata prima di raggiungere WordPress. È un semplice firewall lato server, molto performante.
Con Apache (file .htaccess)
Inserite regole in un .htaccess all'interno della directory /wp-admin/ (o nel .htaccess principale con un blocco mirato). A seconda della versione di Apache, la sintassi differisce:
Apache 2.4+ (consigliato) : consentire solo alcuni IP e rifiutare il resto. Aggiungerete righe del tipo Require ip … (es. IP fisso dell’ufficio) e Require all denied per bloccare per default.
Attenzione : se usate l’editor di temi/plugin dall’admin, avrete bisogno di accesso completo; ma in un’ottica di sicurezza è preferibile disattivare l’editor dall’admin e lavorare via SFTP.
Con Nginx (blocco location)
Su Nginx userete direttive allow/deny in un blocco location rivolto a /wp-admin/. Questo impedisce la maggior parte delle scansioni e degli attacchi brute force a livello server, senza sollecitare PHP.
Punto critico: non rompere admin-ajax.php
Molti temi e funzionalità (incluso lato pubblico) usano admin-ajax.php. Se bloccate tutto /wp-admin/ senza eccezioni, alcune azioni del sito potrebbero smettere di funzionare. Una buona pratica è autorizzare esplicitamente l’accesso a /wp-admin/admin-ajax.php dall’esterno, o di trattare questo punto caso per caso a seconda del vostro sito.
Se cercate resoconti pratici sulle varianti di implementazione a seconda dell’hosting, potete consultare questo thread esterno: Come proteggere l’URL wp-admin?.
Proteggere l’accesso con autenticazione HTTP (Basic Auth)
Il principio: prima ancora di arrivare a WordPress, il server richiede un nome utente/password HTTP. È una seconda barriera molto efficace contro i bot, e una soluzione robusta quando non avete un IP fisso (smart working, spostamenti, 4G…).
Su Apache ciò avviene classicamente tramite un file .htpasswd e un .htaccess che abilita l’autenticazione. Su Nginx si dichiara auth_basic sulla location /wp-admin/ (e eventualmente /wp-login.php). Risultato: anche se un attaccante conosce le credenziali WordPress, dovrà prima superare questo controllo.
Per saperne di più sui nostri servizi di manutenzione di siti WordPress
Buone pratiche: usate una password lunga e unica, evitate di riutilizzare le credenziali WordPress e cambiate questo segreto se un collaboratore lascia il progetto.
Spostare o nascondere il punto di accesso: utile, ma da maneggiare con cautela
Senza plugin, spostare realmente wp-admin è delicato, perché WordPress si aspetta percorsi standard. Invece, potete ridurre la visibilità e complicare l’accesso automatico tramite regole server, ad esempio filtrando pattern, limitando wp-login.php, o autorizzando alcune route solo a determinate condizioni.
Esistono diverse approcci (riscrittura, restrizioni, risposte specifiche). Per confrontare metodi accessibili e comprendere i compromessi (manutenzione, compatibilità), questa risorsa esterna può aiutare: Nascondere wp-admin: 3 metodi semplici per … – Lyode.
Nella pratica, nascondere non sostituisce il controllo degli accessi. Consideralo come uno strato di attrito aggiuntivo, mai come la serratura principale.
Limitare wp-login.php: filtrare, rallentare e bloccare gli abusi
La pagina wp-login.php è l’altra grande target. Senza plugin, puoi comunque ridurre l’esposizione:
1) Limitare per IP : stessa logica di /wp-admin/, con una regola specifica sul file wp-login.php.
2) Bloccare alcuni metodi o parametri : a seconda del contesto, è possibile rifiutare richieste sospette (es. alcuni user agent, raffiche di POST, pattern noti).
3) Aggiungere intestazioni di sicurezza e regole anti-enumerazione : non è un rate limit completo, ma limita le informazioni sfruttabili.
Se desideri una panoramica sulla messa in sicurezza di un sito WordPress senza plugin (oltre al solo accesso admin), puoi leggere: Come mettere in sicurezza il proprio sito WordPress senza plugin.
Disattivare la modifica dei file dall’amministrazione
L’editor del tema e l’editor dei plugin nell’admin sono obiettivi privilegiati: se un account admin viene compromesso, l’attaccante può iniettare codice immediatamente. Senza plugin, puoi disabilitare questa possibilità aggiungendo una costante in wp-config.php. Questo non impedisce l’installazione di plugin, ma rimuove una via di iniezione diretta molto frequente.
Questa misura è particolarmente pertinente se più amministratori hanno accesso al sito, o se il sito è già stato vittima in passato di credenziali deboli.
Forzare HTTPS e rinforzare i cookie di autenticazione
Se l’amministrazione passa a HTTP (anche temporaneamente), esponi la sessione e le credenziali. Assicurati che:
1) Il certificato TLS sia valido (nessun errore del browser).
2) Le redirezioni HTTP → HTTPS siano attive (idealmente lato server).
3) L’URL di WordPress e l’URL del sito siano entrambe in https nelle impostazioni.
Puoi anche attivare impostazioni che rafforzano l’uso dei cookie sicuri. L’idea: evitare che un cookie di autenticazione circoli in chiaro o in un contesto non previsto.
Impedire l’enumerazione degli utenti (e ridurre gli indizi forniti agli aggressori)
Molti attacchi brute force iniziano trovando credenziali valide. WordPress può divulgare indizi (autore, endpoint, risposte). Senza plugin, puoi:
1) Bloccare alcune richieste agli archivi autore se rivelano login sfruttabili (a seconda del tema e della configurazione).
2) Verificare le risposte e gli errori di accesso : messaggi troppo precisi facilitano il lavoro dei bot.
3) Limitare l'esposizione di alcune route in base a ciò che è realmente necessario per il sito.
L'obiettivo non è rompere tutto, ma rimuovere le informazioni gratuite che rendono le campagne automatizzate più efficaci.
Restringere XML-RPC se non lo usi
XML-RPC è stato a lungo una porta d'ingresso per attacchi (bruteforce, pingback). Se il tuo sito non utilizza funzionalità che ne dipendono (alcune app, integrazioni vecchie), puoi disabilitarlo lato server o tramite una configurazione in WordPress (senza plugin). In caso di dubbio, testa: pubblicazione remota, integrazioni, strumenti di monitoraggio, ecc.
Un approccio prudente è bloccare XML-RPC ai visitatori pubblici permettendo però IP specifici se un'integrazione legittima ne dipende.
Rinforzare i permessi dei file e la proprietà (la base spesso trascurata)
Puoi avere la migliore protezione su wp-admin, ma se i permessi dei file sono troppo permissivi, una semplice vulnerabilità altrove può permettere la scrittura di file dannosi.
Riferimenti comuni (da adattare in base all'hosting) :
1) Directory : permessi ragionevoli (spesso 755).
2) File : permessi più restrittivi (spesso 644).
3) wp-config.php : particolarmente sensibile, da limitare ulteriormente se possibile.
4) Proprietà : evitate i proprietari incoerenti che poi impongono permessi troppo aperti affinché funzioni.
Mettere in atto intestazioni di sicurezza utili all’admin
Le intestazioni HTTP non proteggono wp-admin da una password debole, ma riducono alcuni rischi correlati (clickjacking, injection nel contesto del browser, ecc.). A seconda della vostra configurazione, potete applicare:
X-Frame-Options O frame-ancestors (CSP) per limitare l’incorporamento dell’admin in un iframe.
X-Content-Type-Options: nosniff per evitare alcuni comportamenti di sniffing.
Referrer-Policy per controllare le perdite di referrer.
Testare dopo il deployment, poiché alcune policy CSP severe possono interferire con script legittimi, in particolare nell’editor a blocchi.
Per saperne di più sui nostri servizi di manutenzione di siti WordPress
Sorvegliare i segnali deboli: quando la sicurezza provoca sintomi
Un indurimento aggressivo può creare effetti collaterali: loop di redirect, errori 403 inattesi, pagine di accesso non raggiungibili, chiamate AJAX interrotte o comportamenti casuali a seconda dei ruoli. A ogni fase, convalidare:
1) Accesso/uscita (incluso Password dimenticata).
2) Pubblicazione (editor, media, aggiornamenti).
3) Funzioni front dipendenti da admin-ajax.php o da API.
Se ti trovi di fronte a un blocco completo (in particolare dopo una modifica server), questo tipo di situazione può a volte somigliare a un guasto più generale. In caso di dubbio, questo contenuto può aiutarti a diagnosticare: WordPress Schermo Bianco: Cause e Soluzioni.
Non confondere sicurezza e prestazioni: evitate toppe inutili
Accumular regole senza logica può rendere il sito fragile: riparate un sintomo, ma aumentate la complessità e il rischio di errore. L’approccio più sano consiste nel:
1) Scegliere 2–4 misure forti (allowlist IP, Basic Auth, HTTPS rigoroso, disattivazione dell’editing, XML-RPC se inutile).
2) Documentare ciò che è stato fatto (dove, perché, come tornare indietro).
3) Testare dopo ogni modifica.
E quando dovete davvero aggiungere un’estensione, fatelo per una ragione chiara e con un arbitrato sulla qualità. A questo proposito, potete consultare: Plugin Gratuito vs Plugin Premium: Cosa Scegliere?.
Igiene complessiva: un accesso admin solido non basta se il sito è già indebolito
Même avec un accès admin très verrouillé, un site encombré (thèmes inactifs, plugins abandonnés, comptes inutiles, tables orphelines) augmente le risque : plus de code, plus de surface, plus de points de rupture. Un minimum d’entretien aide indirectement la sécurité.
Si vous souhaitez rationaliser l’existant (sans promettre que SEO = sécurité, mais parce que l’hygiène technique compte), vous pouvez lire : Pulire WordPress per Migliorare la SEO.
Cas multi-sites et équipes : standardiser les règles
Quand vous gérez plusieurs sites (ou plusieurs environnements : dev, staging, prod), la sécurisation de l’admin devient un sujet d’industrialisation : mêmes règles, mêmes exceptions, mêmes tests, mêmes procédures de secours. Sans cela, vous finissez avec des configurations artisanales difficiles à maintenir, et donc plus risquées.
La standardisation passe souvent par : un modèle de configuration serveur, un guide d’accès (IP/VPN/Basic Auth), une rotation des secrets, et un contrôle régulier des comptes administrateurs.
Pour une méthode d’organisation et de suivi au quotidien, vous pouvez consulter : Come Gestire un Parco di Siti WordPress in Modo Efficace.
Éviter les impacts SEO et d’indexation lors du durcissement
En verrouillant des URLs, on peut involontairement bloquer des ressources nécessaires au rendu (scripts, endpoints), ou générer des codes HTTP inattendus. Normalement, wp-admin et wp-login ne doivent pas être indexés, mais certaines erreurs de configuration peuvent aussi toucher le front (règles trop larges, includes mal ciblés, redirections globales).
Après vos changements, vérifiez que Google peut toujours explorer les pages publiques, que les codes 200/301/404 sont cohérents, et qu’aucune ressource critique n’est bloquée. Pour un process de vérification, vous pouvez lire : Come Verificare che WordPress sia Indicizzato Correttamente.
Plan de mise en œuvre recommandé (sans plugin)
Per ottenere un risultato netto e duraturo, applica questo piano evitando di cambiare tutto in una volta :
Fase 1 : forzare HTTPS ovunque (incluso admin) e convalidare i reindirizzamenti.
Fase 2 : aggiungere una protezione server su /wp-admin/ (allowlist IP se possibile, altrimenti Basic Auth).
Fase 3 : gestire wp-login.php (restrizione per IP, filtraggio minimale e test degli scenari).
Fase 4 : disattivare la modifica dei file nell'admin, rivedere gli account, eliminare gli utenti non necessari.
Fase 5 : limitare XML-RPC se non usato, verificare admin-ajax.php, testare front/back.
Passo 6 : documentare e mettere in atto una routine (controllo degli accessi, rotazione dei segreti, audit regolare).
Quando affidare questo a una manutenzione (e perché non è solo una semplice impostazione)
Sulla carta queste misure sono semplici. In produzione la difficoltà nasce dai casi particolari: IP che cambiano, CDN/proxy, regole Nginx/Apache diverse, temi che dipendono da AJAX, integrazioni di terze parti, staging, multi-admin, ecc. Una regola errata può chiudervi fuori o rompere delle funzionalità.
Se volete un'implementazione pulita, testata, documentata, con una rete di sicurezza (backup, procedura di rollback, monitoraggio), potete ricorrere a un servizio dedicato: Per saperne di più sui nostri servizi di manutenzione di siti WordPress.
