Cacher sa page de connexion WordPress aux bots et attaques
Chaque site WordPress a sa connexion à la même URL, cible de tous les bots : wp-login.php. Déplacez-la vers un slug secret et renvoyez les intrus en 404.
Tous les sites WordPress de la planète ont leur connexion à la même adresse : wp-login.php. Tous les bots de force brute la connaissent, tous les scanners de vulnérabilités l’essaient en premier, et rien dans WordPress d’origine ne permet d’en changer — l’URL est codée en dur. Votre page de connexion se fait donc marteler jour et nuit par des scripts qui ne s’arrêteront jamais, parce qu’ils savent toujours exactement où frapper. La réponse la plus efficace n’est pas une serrure plus grosse. C’est de déplacer la porte.
L’essentiel
- Chaque connexion WordPress vit à
wp-login.php— une cible universelle que tous les bots connaissent déjà. - Le module déplace la connexion vers un slug secret et redirige l’ancienne URL et
/wp-admin(pour les visiteurs déconnectés) vers une 404 ou n’importe quelle page de votre choix. - Il épargne AJAX, API REST, XML-RPC, cron et CLI : extensions, applications et tâches planifiées continuent de fonctionner.
- Les slugs réservés (
wp-admin,login,xmlrpc.php…) sont bloqués, et le slug de connexion est exclu du cache de pages — impossible de le casser ou de l’exposer par accident. - Il est désactivé tant que vous ne l’activez pas, vous rappelle de mettre l’URL en favori, et recommande de l’associer à Fatal Error Recovery comme filet de sécurité anti-enfermement.
Pourquoi wp-login.php pose-t-il un tel problème ?
Parce que WordPress ne vous offre aucun moyen intégré de changer l’URL de connexion, de bloquer l’accès direct à wp-login.php, de tenir les visiteurs déconnectés hors de /wp-admin, ou de rediriger les tentatives ailleurs. La page de connexion reste donc là, identique et prévisible, sur des millions de sites.
Le résultat, c’est un trafic automatisé incessant. Les bots n’ont pas besoin de réussir pour vous coûter cher : ils brûlent des ressources serveur, noient vos journaux sous les tentatives échouées, et peuvent visiblement ralentir un petit site rien qu’en frappant des milliers de fois par jour. La limitation de tentatives et les CAPTCHA combattent ce trafic une fois qu’il est arrivé. Cacher la connexion supprime la cible pour que le trafic n’arrive jamais — si un bot ne trouve pas la porte, il ne peut pas la marteler.
Comment cacher sa page de connexion WordPress ?
Activez le module Hide Login Page de Blaminhor Essentials, puis réglez deux choses : un slug de connexion secret qui remplace wp-login.php, et la destination de tous les autres — votre 404 ou n’importe quelle page de votre choix. Les utilisateurs connectés accèdent toujours à l’administration normalement, et AJAX, REST, cron et CLI restent intacts : rien ne casse sur votre site.
Deux champs — votre slug de connexion secret et la destination de tous les autres — plus un rappel intégré de mettre en place la récupération avant d’activer.
Choisir une URL de connexion secrète
Remplacez wp-login.php par un slug de votre choix : votre connexion devient votresite.com/ma-porte-secrete/ au lieu de l’adresse que tous les bots essaient. Rendez-le mémorisable mais pas devinable — évitez les choix évidents comme admin, login ou signin. Le module bloque activement les slugs réservés (wp-admin, wp-login, xmlrpc.php et compagnie) pour que vous ne puissiez pas choisir quelque chose qui entrerait en collision avec WordPress lui-même.
Renvoyer tous les autres ailleurs
Une fois le module activé, quiconque atteint wp-login.php ou /wp-admin sans être connecté est redirigé — par défaut vers votre 404, ou vers l’URL de votre préférence (votre page d’accueil, une page personnalisée). Ces visiteurs ne voient jamais de formulaire de connexion, et n’apprennent jamais qu’il en existe un à ce slug. Les utilisateurs connectés accèdent à l’administration normalement, et les requêtes AJAX, API REST, XML-RPC, cron et CLI ne sont pas touchées : rien ne casse sur votre site. Le slug de connexion personnalisé est même exclu du cache de pages, pour qu’une couche de cache ne puisse pas le servir ou l’exposer par accident.
Voici ce qui change pour chaque type de requête, histoire de constater qu’aucune requête légitime ne se fait attraper :
| Requête | WordPress par défaut | Avec Hide Login Page |
|---|---|---|
wp-login.php dans un navigateur (déconnecté) | Formulaire de connexion montré à tous | Redirigé vers une 404 ou la page de votre choix |
/wp-admin (déconnecté) | Renvoie vers wp-login.php | Redirigé ailleurs — aucune connexion révélée |
| Votre slug secret | N’existe pas | Affiche le formulaire de connexion |
| AJAX | Fonctionne | Intact — délibérément ignoré |
| API REST | Fonctionne | Intact — délibérément ignoré |
| XML-RPC | Fonctionne | Intact — délibérément ignoré |
| Cron / WP-CLI | Fonctionnent | Intacts — délibérément ignorés |
Et si je m’enferme dehors ?
C’est le seul risque réel quand on cache une connexion : oubliez l’URL personnalisée et vous voilà dehors, vous aussi. Le module intègre deux garde-fous.
- Mettez l’URL en favori. Le module affiche un rappel clair avant l’activation — enregistrez le slug dans un endroit de confiance.
- Activez d’abord Fatal Error Recovery. Ce module compagnon fournit une URL de récupération secrète qui fonctionne toujours, même si vous perdez votre adresse de connexion personnalisée. Hide Login recommande explicitement de l’activer avant de basculer — deux modules du même plugin qui se connaissent l’un l’autre, exactement le genre de filet de sécurité que des outils séparés ne vous donneront jamais.
Un exemple concret
Imaginons que vous gériez un site client et vouliez une connexion invisible pour les bots comme pour le client :
- Activez Hide Login Page.
- Réglez le slug de connexion sur quelque chose comme
acces-client. - Réglez la redirection sur
404. - Activez Fatal Error Recovery et enregistrez son URL de récupération en lieu sûr.
- Activez la protection.
Désormais, votresite.com/wp-login.php et votresite.com/wp-admin/ renvoient tous deux une 404. La seule entrée est votresite.com/acces-client/. Les bots qui scannent wp-login.php ne trouvent rien, les scripts de force brute n’ont plus de cible, et vos journaux retrouvent le silence.
Une sécurité simple, sans surcoût
Déplacer votre connexion ne touche ni à vos mots de passe ni à votre double authentification — ça supprime la cible dont dépendent toutes les attaques automatisées. Pas de .htaccess à éditer, pas de configuration serveur, aucun coût en performance : juste une URL différente, et un site beaucoup plus silencieux. Associez-le aux modules HTTPS Redirect et Fatal Error Recovery, et votre surface de connexion devient à peu près aussi réduite que WordPress le permet.
Hide Login Page est l’un des plus de 20 outils de Blaminhor Essentials — gratuit et open source sur WordPress.org.
Télécharger Blaminhor Essentials
– blaminhor
FAQ
Cacher la page de connexion arrête-t-il vraiment les attaques par force brute ?
Ça arrête les attaques automatisées, c'est-à-dire l'immense majorité. Les bots martèlent wp-login.php parce que c'est la même URL sur tous les sites ; déplacez la connexion vers un slug secret et ils tombent sur une 404, sans rien à attaquer. Un humain déterminé qui trouverait votre slug aurait toujours besoin de votre mot de passe — gardez-le solide, lui aussi.
Cacher ma connexion va-t-il casser l'AJAX, l'API REST ou le cron ?
Non. Le module ignore délibérément les requêtes AJAX, API REST, XML-RPC, cron et CLI : les extensions, les applications et les tâches planifiées continuent de fonctionner normalement. Seules les requêtes de navigateur humaines vers l'ancienne page de connexion et vers wp-admin par des visiteurs non connectés sont redirigées ailleurs.
Comment changer aussi l'URL de wp-admin ?
On ne renomme pas /wp-admin — il reste en place, mais le module redirige tout visiteur déconnecté qui s'y présente directement vers votre 404 ou la page de votre choix : personne sans session ne voit jamais un formulaire de connexion. Une fois votre slug secret, /wp-admin devient une impasse pour les bots ; les utilisateurs connectés y accèdent normalement.
Cacher la connexion vaut-il mieux que limiter les tentatives ou la double authentification ?
C'est complémentaire, pas un remplacement. La limitation de tentatives et la double authentification combattent les attaques une fois qu'elles atteignent votre connexion ; cacher la page fait que la plupart n'arrivent jamais, ce qui réduit le bruit que ces outils doivent gérer. La configuration la plus solide superpose les trois — slug caché, tentatives limitées et double authentification — plutôt que de miser sur un seul.
Et si j'oublie mon URL de connexion personnalisée et me retrouve enfermé dehors ?
C'est le seul vrai risque : mettez l'URL en favori et associez le module à Fatal Error Recovery, un module compagnon qui vous donne un lien de récupération secret qui fonctionne toujours. Hide Login vous rappelle même de l'activer d'abord. Les slugs réservés comme wp-admin ou login sont aussi bloqués, pour que vous ne puissiez pas choisir une URL qui se saboterait elle-même.
Cacher ma connexion va-t-il interférer avec le cache de pages ?
Non. Le module exclut automatiquement votre slug de connexion personnalisé du cache de pages : une couche de cache ne peut donc pas stocker la page de connexion par accident, en servir une version périmée, ou exposer le slug dans une URL mise en cache. Tout le reste se met en cache normalement — seule la route de connexion sensible est délibérément tenue à l'écart.
Commentaires