Les tentatives de connexion répétées sur WordPress ne sont pas un scénario théorique. Ça se voit dans les journaux, ça se ressent sur les performances lors de pics, et surtout ça finit par user les équipes qui gèrent le site. La bonne nouvelle, c’est qu’on peut réduire la surface d’attaque de manière très concrète, en combinant plusieurs niveaux de protection: WordPress d’abord, puis le serveur et, si possible, le pare-feu ou un service en amont.
Dans ce tutoriel, je vous propose une approche pragmatique pour bloquer ou ralentir les tentatives de connexion. L’objectif n’est pas de “faire disparaître” toute tentative (ce serait illusoire), mais de rendre l’accès forcé inutile, coûteux et rapidement détectable. On parle ici de sécuriser site WordPress, en gardant un niveau de contrôle raisonnable et sans casser l’accès légitime à votre administration.
Comprendre ce qui se passe vraiment
Quand des robots tentent de se connecter à WordPress, ils suivent souvent des schémas assez constants: ils ciblent l’URL de connexion, devinent des identifiants courants, essaient des paires mot de passe et utilisateur, puis recommencent depuis d’autres IP. Parfois ils utilisent aussi des erreurs de configuration, comme une exposition de pages internes, ou des mécanismes d’authentification trop permissifs.
Trois points reviennent dans la pratique.
D’abord, le “bruit” dans les logs ne veut pas dire que tout est bloquable au même endroit. WordPress peut afficher des erreurs et refuser des connexions, mais si vous avez des centaines de requêtes par minute sur /wp-login.php, vous allez déjà subir la charge (CPU, bande passante, I/O).
Ensuite, un blocage “trop strict” peut se retourner contre vous. Si vous activez un blocage par IP sans seuil adapté, vous risquez de verrouiller vos propres accès lors d’un changement d’adresse IP, d’un VPN, ou d’une connexion mobile instable. C’est un problème classique sur les sites d’entreprise quand des collaborateurs changent de réseau.
Enfin, certaines mesures sont plus efficaces en amont que dans WordPress. Un filtrage au niveau serveur ou un pare-feu qui coupe avant d’atteindre PHP réduit la charge. Une limite de tentatives dans WordPress est utile, mais elle travaille après l’appel PHP, donc après une partie du coût initial.
Pré-requis et précautions avant de modifier
Avant toute modification, prenez deux habitudes simples.
1) Vérifiez que vous pouvez restaurer rapidement un accès administrateur. Un moyen courant est de garder un compte “secours” et un accès via votre hébergeur (souvent un accès direct au panneau, ou une procédure de réinitialisation).
2) Travaillez par étapes, pas tout d’un coup. Si vous bloquez trop tôt, vous ne saurez pas quelle mesure a causé le blocage.Sur WordPress, réfléchissez aussi à l’impact sur les outils. Si vous utilisez des plugins de formulaire, des applications mobiles, des clients API, ou une intégration qui se connecte à distance, une restriction de tentatives peut impacter ces systèmes, surtout si un token est renouvelé de manière brutale.
Mesure 1: limiter les tentatives de connexion côté WordPress
La façon la plus directe est d’ajouter une limite de tentatives. Plusieurs plugins le font, mais je préfère une approche qui garde le contrôle et limite la complexité. Vous avez essentiellement deux voies:
- Passer par un plugin de sécurité qui inclut une limitation de tentatives. Configurer une protection similaire via règles et filtres, ou un mécanisme de limitation selon votre configuration.
Dans la réalité, l’option plugin est souvent la plus rapide. Le point clé, ce n’est pas “quel plugin”, mais comment vous réglez les seuils, la durée de blocage et surtout l’exclusion de vos IP fiables.
Par exemple, pour un site personnel peu exposé, un seuil trop agressif peut bloquer un utilisateur légitime qui saisit son mot de passe avec une faute à la première tentative. Pour un site institutionnel déjà très ciblé, vous pouvez accepter des seuils plus bas, car les robots sont très réguliers et le trafic est plus massif.
Un bon réglage de départ dépend de votre volume. Si vous recevez très peu de tentatives, augmentez un peu le seuil pour éviter les blocages. Si vous voyez déjà des centaines de tentatives sur /wp-login.php chaque heure, vous pouvez être plus strict.
Voici un exemple de démarche, orientée “sans surprise”, qui combine WordPress et serveur:
Étapes recommandées (progressives)
Activez une limitation de tentatives dans WordPress via un plugin (ou une fonctionnalité de sécurité équivalente), avec un blocage temporaire et des seuils raisonnables. Excluez vos IP fixes (bureau, réseau de l’entreprise) ou un sous-réseau de confiance, pour éviter les verrouillages accidentels. Vérifiez les logs après 24 à 48 heures: nombre de tentatives, proportion de blocages, et s’il y a eu des erreurs pour vos propres connexions. Si le volume reste élevé, renforcez la durée de blocage ou réduisez le seuil, par petites touches. Finalisez en ajoutant un filtrage au niveau serveur pour couper une partie du trafic avant PHP.Même en utilisant un plugin, vous gardez de la marge si vous faites un réglage progressif. Cette méthode réduit fortement les connexions à répétition, tout en évitant la mauvaise surprise “je n’arrive plus à me connecter”.
Mesure 2: filtrer avant WordPress avec le serveur (Apache et Nginx)
Limiter dans WordPress, c’est bien. Mais la cible des robots est souvent l’entrée: /wp-login.php. Si vous pouvez bloquer ou filtrer au niveau serveur, vous réduisez à la fois la charge et le bruit.
La logique générale est simple: créer une règle qui limite les requêtes par IP vers l’endpoint de connexion, ou qui déclenche un blocage après un certain nombre de tentatives sur une fenêtre de temps.
Le détail dépend de votre stack.
Si vous utilisez Apache
Vous pouvez recourir à des modules comme mod_evasive ou mod_security (selon votre hébergeur et votre configuration). Sur certains hébergements, mod_evasive est disponible, sur d’autres non. Si l’hébergeur contrôle la configuration, vous n’avez pas la main, et il vaut mieux passer par les options disponibles dans le panneau.
Si, en revanche, vous avez accès à la configuration et aux directives autorisées, vous pouvez appliquer des limites sur des chemins précis, comme /wp-login.php. L’avantage, c’est que les robots sont stoppés très tôt, avant le déclenchement de PHP.
Si vous utilisez Nginx
Nginx est souvent plus facile à raisonner pour ce type de contrôle, car il gère nativement des notions de zones partagées, de limites de requêtes, et de règles sur les URIs. Là aussi, l’endpoint ciblé est fréquemment /wp-login.php et parfois /xmlrpc.php.
Attention, sur certains sites, les clients légitimes appellent xmlrpc.php pour des fonctionnalités anciennes, ou pour des intégrations. Si vous bloquez cet endpoint sans vérifier vos usages, vous risquez de casser des flux. J’y reviens plus loin.
Mesure 3: protéger spécifiquement l’URL de connexion et réduire l’exposition
Une autre approche consiste à réduire la visibilité de la page de connexion. Certains configurent un remplacement de l’URL de connexion, d’autres ajoutent des restrictions supplémentaires.
Le risque, c’est que changer l’URL de connexion peut créer des effets de bord si vous avez des systèmes externes, ou si des plugins tiers s’attendent à des URL standard. Mais si votre site est géré “en interne” et que vous documentez l’accès, la réduction d’exposition peut faire une vraie différence.
Ce que je recommande en pratique, c’est de voir cela comme un filtre additionnel, pas comme l’unique barrière. Les robots automatisés finissent souvent par adapter leurs tentatives, surtout si l’accès est public et l’info circulent. Mais moins de bruit au départ, c’est déjà ça.
Mesure 4: traiter le cas xmlrpc.php avec discernement
Beaucoup de tentatives de connexion s’accompagnent de requêtes vers xmlrpc.php. Cet endpoint historique sert à des fonctionnalités de WordPress qui permettent des méthodes distantes. Il a aussi été impliqué dans des scénarios abusifs, notamment en lien avec des attaques par amplification ou par méthodes de bruteforce.
La question n’est pas “faut-il le bloquer”, c’est plutôt “l’utilisez-vous vraiment ?”.
Si vous n’utilisez pas de clients XML-RPC, vous pouvez bloquer l’endpoint au niveau serveur. C’est souvent un levier efficace, parce que le trafic abusif y est relativement fréquent.
Mais si vous avez des intégrations qui passent par XML-RPC, vous devez valider. Dans les organisations, c’est un point où je vois souvent des déploiements casser quelque chose deux semaines plus tard, quand un plugin ou un outil d’intégration est redécouvert ou mis à jour.
Mon conseil: cherchez dans votre installation des plugins liés à la publication à distance, à des clients particuliers, ou à des usages historiques. Si vous êtes incertain, commencez par mettre une surveillance, puis testez un blocage sur une période courte.
Mesure 5: renforcer l’hygiène WordPress, les comptes et l’authentification
Les robots n’attaquent pas seulement des URL, ils attaquent aussi des comptes. Or WordPress laisse parfois des signatures utiles pour l’attaquant, notamment via l’existence de certains utilisateurs.
Vous pouvez rendre l’attaque moins efficace en travaillant sur:
- la qualité des mots de passe, le blocage des comptes inactifs, la réduction du nombre de comptes “anciens” ou non utilisés, et l’ajout d’une authentification à facteurs si possible.
L’authentification multifacteur est une mesure très puissante. Elle ne bloque pas la tentative d’authentification, mais elle empêche l’accès, même si le mot de passe est deviné. Pour un robot, le coût explose, car il doit gérer un second facteur qui nécessite une action humaine ou un mécanisme matériel.
Il y a toutefois un point de vigilance: si vous activez un MFA, assurez-vous que vos méthodes de secours sont fonctionnelles (codes imprimés, clés de secours, ou compte de secours). Les pannes d’authentification sont rares, mais quand elles arrivent, elles sont particulièrement pénibles.
Vérifier que la protection tient la route
Une règle de base: une sécurité utile se mesure. Vous voulez savoir si les tentatives diminuent, si votre serveur souffre moins, et si vous n’avez pas créé un blocage pour de vrais utilisateurs.
Après activation des mesures, je vous conseille une courte phase d’observation, puis des ajustements.
Voici une mini grille de vérification, simple et efficace.
Contrôlez dans vos logs que les requêtes sur /wp-login.php diminuent ou changent de nature (moins de succès, plus de refus). Vérifiez la charge serveur pendant les pics, pas seulement le nombre d’erreurs. Une baisse de charge est souvent le vrai signal. Faites un test de connexion depuis votre réseau habituel, puis depuis un autre réseau (mobile par exemple) pour voir si un blocage IP temporaire vous touche. Si vous utilisez un plugin de limitation, inspectez ses paramètres et vérifiez que vos IP ne sont pas traitées comme anonymes. Surveillez les événements WordPress liés à la connexion, pas uniquement les logs serveur, car certains plugins créent des alertes utiles.Cette étape évite le piège du “ça a l’air mieux” pendant deux jours, puis une situation de blocage non anticipée deux semaines après.
Cas particuliers qui posent problème (et comment éviter de vous piéger)
Il y a quelques cas où les mesures automatiques se retournent contre vous.
Le premier, c’est l’accès depuis des réseaux variables. Si vous travaillez souvent via mobile, si vous utilisez un VPN, ou si vous changez régulièrement de fournisseur, le “blocage par IP” peut vous toucher. La solution est de prévoir des exclusions pour vos IP, ou de choisir un mécanisme de limitation qui pénalise la tentative tout en gardant une fenêtre tolérante pour les utilisateurs légitimes.
Le second, c’est le partage d’IP. Dans les entreprises, plusieurs employés peuvent sortir par la même IP publique. Un seuil trop bas peut alors bloquer tout le monde. Dans ce cas, il faut ajuster le seuil ou utiliser une stratégie plus fine, en combinant l’authentification multifacteur et une tolérance par fenêtre.
Le troisième, c’est l’API ou les intégrations. Certaines intégrations WordPress se reconnectent fréquemment. Si elles utilisent des identifiants WordPress classiques, une limitation peut les impacter. Je préfère, quand c’est possible, utiliser des mécanismes d’authentification dédiés aux intégrations, ou des clés, plutôt que des identifiants humains qui vont déclencher des blocages.
Enfin, il y a le piège des faux positifs côté sécurité. Si vous installez plusieurs couches, certaines règles peuvent entrer en conflit. Par exemple, un pare-feu peut déjà bloquer une plage d’IP, et un plugin peut interpréter le tout comme un grand nombre d’échecs et activer des sanctions supplémentaires. Résultat: au lieu de réduire le problème, vous le rendez moins lisible. D’où l’intérêt de régler par étapes et de vérifier les logs.
Un exemple réaliste de déploiement en production
Sur un site vitrine que je gérais, le trafic vers /wp-login.php était relativement faible le matin, puis montait nettement le soir. Au début, on avait mis une limitation dans WordPress seule. Ça a réduit l’impact, mais la charge restait visible. Les bots arrivaient quand même, déclenchaient du PHP, et le serveur montait en charge lors des pics.
On a ensuite ajouté un filtrage au niveau serveur sur l’endpoint de connexion, sans toucher aux fonctionnalités légitimes. Puis on a activé un MFA pour les comptes administrateurs, et on a désactivé les comptes obsolètes.
Le résultat a été net: moins de bruit, moins de requêtes qui atteignent WordPress, et surtout une tranquillité administrative. Le point le plus important, c’était la méthode. On ne l’a pas tout activé le même jour. On a ajusté selon les logs, ce qui a évité les blocages “surprise”.
Choisir les bons seuils: l’erreur la plus fréquente
Beaucoup de gens fixent un seuil “au feeling”. C’est compréhensible, https://gardewp.fr/securite-wordpress/ mais ça finit par être dangereux.
Un seuil trop bas, vous bloquez des utilisateurs, surtout ceux qui ont un mot de passe oublié ou qui se connectent depuis un réseau instable.
Un seuil trop haut, les robots continuent à marteler le site, ce qui entretient la charge et la fatigue opérationnelle.
La meilleure approche est de partir d’un seuil modéré, puis d’ajuster en fonction de votre observation. Sur un site très exposé, vous pouvez descendre progressivement. Sur un site plus calme, gardez un seuil plus tolérant et appuyez-vous davantage sur MFA et sur des mesures serveur.
Étapes finales de durcissement (sans tout casser)
Une fois que vous avez limité les tentatives, gardez votre focus sur l’architecture de confiance:
- compte administrateur en nombre réduit, rotation des mots de passe si nécessaire, suppression ou verrouillage des comptes inactifs, MFA pour les rôles à risque, et règles serveur ciblées sur les endpoints réellement exposés.
Ces mesures n’ont pas besoin d’être spectaculaires pour être efficaces. Le plus dur, c’est de maintenir la discipline dans le temps. Un site WordPress “bien sécurisé” au départ peut se dégrader avec le temps, parce que des comptes sont ajoutés, des plugins sont installés, et les usages changent.
Conclusion opérationnelle, sans magie
Bloquer les tentatives de connexion sur WordPress, ce n’est pas une seule commande, c’est une combinaison. WordPress aide à limiter les échecs, le serveur coupe une partie du trafic avant PHP, et les bonnes pratiques d’accès (mots de passe, MFA, comptes propres) empêchent l’attaque de devenir utile.
Si vous ne deviez retenir que deux actions immédiates, ce serait: limiter les tentatives de connexion dans WordPress avec une mise au point progressive, puis ajouter un filtrage serveur ciblé sur les endpoints sensibles. Le reste vient ensuite, avec un ajustement basé sur les logs.
Vous voulez que je vous aide à adapter les réglages à votre cas? Donnez-moi votre configuration (Apache ou Nginx, présence de Cloudflare ou non, et si vous utilisez xmlrpc.php), et je vous proposerai des seuils de départ et une stratégie de déploiement plus précise.