Quand on parle de renforcer la sécurité WordPress, on pense souvent aux mots de passe, aux mises à jour, à la désactivation des plugins inutiles. Tout juste. Mais il y a un autre levier, plus discret, qui joue pourtant un rôle réel dans la résistance au “bruteforce” et aux tentatives d’identification : la manière dont WordPress réagit quand quelqu’un se trompe.
Dans la pratique, les erreurs affichées au moment de la connexion peuvent donner des indices. Pas toujours, pas de façon spectaculaire, mais suffisamment pour qu’un attaquant automatise ses tentatives, ou qu’il affine son approche. L’objectif n’est pas de rendre WordPress “inattaquable”, c’est une promesse que personne ne peut tenir honnêtement. L’objectif raisonnable, c’est de réduire la valeur des informations en clair, et d’éviter qu’un test de nom d’utilisateur ou d’e-mail se transforme en enquête.
Cet article explique comment cacher les réponses d’erreurs d’identification dans WordPress, ce que ça change vraiment, les limites à connaître, et comment le combiner avec d’autres protections concrètes.
Pourquoi les messages d’erreur comptent
Imaginez un scénario simple. Quelqu’un teste une liste de noms d’utilisateur contre votre site. Si WordPress répond différemment selon que le nom existe ou non, l’attaquant gagne un avantage : il peut concentrer ensuite ses efforts sur les comptes “valides”.
Dans beaucoup d’installations, les messages diffèrent déjà selon la nature de l’erreur. Exemple typique côté interface : si le champ identifiant est vide, WordPress le signale, et si l’identifiant est présent mais que le mot de passe ne colle pas, le message ne dit pas exactement la même chose. C’est logique pour un utilisateur humain, beaucoup moins pour un outil automatisé.
Même quand WordPress utilise un message global du type “Identifiants incorrects”, il peut rester des divergences selon les chemins internes du traitement : gestion du champ vide, format invalide, comportement pendant la récupération de mot de passe, ou encore réponses différentes selon le point d’entrée (page de connexion classique, AJAX, endpoints d’authentification).
Le point important, c’est la somme de petits détails. Une information isolée n’est pas une faille en soi, mais elle peut accélérer un assaillant, et surtout lui permettre de mesurer ce qu’il fait. Or la mesure, en sécurité, change tout.
Ce que WordPress fait déjà, et ce qui peut encore fuir
WordPress est assez “conservateur” dans ses messages de connexion, et beaucoup de déploiements observent déjà une réponse générique quand identifiant et mot de passe ne correspondent pas. Dans ce cas, cacher davantage peut sembler inutile.
Sauf que, sur le terrain, on voit souvent deux cas :
Des réponses trop spécifiques quand un champ est vide, ou quand un format n’est pas attendu. Des différences selon le formulaire et le flux utilisé, notamment sur la récupération de mot de passe. La page “perdu” est conçue pour éviter de trop divulguer, mais selon les thèmes, les traductions, les plugins de sécurité, ou les surcharges, le rendu peut diverger.Il faut aussi tenir compte d’un détail souvent oublié : votre but n’est pas uniquement d’afficher un message identique. Vous cherchez à empêcher la “différenciation” utile à un attaquant, ce qui peut inclure le texte, mais aussi le comportement perceptible (temps de réponse, types d’erreurs, codes renvoyés, redirections). Cacher le texte est un bon premier pas, mais ce n’est pas le seul.
La bonne approche : renvoyer un message unique, sans casser l’expérience
Le bon compromis consiste à remplacer le contenu des erreurs affichées lors d’une tentative d’identification échouée, par un message unique et volontairement neutre. Pour un utilisateur humain, il faut que le message soit compréhensible, mais pas instructif pour un bot.
Un message du genre “Identifiants invalides.” ou “Impossible de vérifier vos identifiants. Veuillez réessayer.” marche généralement bien. Il ne donne aucune précision exploitable. Il ne dit pas “ce compte n’existe pas”, il ne confirme pas la présence d’un identifiant, il ne pointe pas un champ exact.
En parallèle, on conserve en interne la granularité nécessaire pour diagnostiquer côté admin. WordPress loguera autrement (selon votre configuration), et des plugins de sécurité sérieux enregistrent les événements utiles sans les exposer au public.
Cacher les erreurs de connexion via un filtre WordPress
Sur WordPress, la voie la plus propre passe par un filtre qui permet de modifier le message renvoyé à l’écran quand l’authentification échoue.
Dans votre plugin “site-specific” ou dans le fichier functions.php de votre thème (en préférant un plugin mu-métier si vous voulez éviter les surprises de mise à jour), vous pouvez ajouter :
Add_filter('login_errors', function($error) // On renvoie une erreur volontairement neutre. // On garde le paramètre pour compatibilité, mais on ne l’expose pas. Return 'Identifiants invalides.'; );Ce snippet a deux intérêts concrets :
- Il évite de distinguer “identifiant incorrect” de “mot de passe incorrect” au niveau de l’interface. Il élimine souvent des variantes liées au formulaire ou à la traduction, si elles finissent dans la même variable affichée.
Cela dit, je le dis clairement pour éviter une fausse impression : selon les configurations, tous les cas ne passent pas forcément par le même chemin. WordPress peut afficher aussi des erreurs de champs requis avant même la tentative d’authentification, ou des messages qui ne se retrouvent pas dans login_errors.
C’est là que l’évaluation sur votre site compte, et pas seulement le code.
Traiter aussi les cas “champ vide” et erreurs de validation
Sur beaucoup de sites, l’internaute voit un message du type “Vous devez remplir ce champ” quand il oublie un identifiant ou un mot de passe. Pour un humain, c’est utile. Pour un attaquant, c’est un signal aussi. Un bot peut adapter son formulaire dès qu’il apprend la règle.
Sans aller jusqu’à une UX pénible, vous pouvez réduire cette différenciation en neutralisant certains messages, ou en masquant le texte tout en conservant la validation technique.
Une approche prudente consiste à agir uniquement quand l’utilisateur a soumis quelque chose, et à limiter le message unique aux erreurs d’authentification plutôt qu’à toutes les validations front. En pratique, il faut tester.
Si vous voulez aller plus loin, vous pouvez combiner le filtre avec d’autres points d’accroche, par exemple au moment où WordPress produit un WP_Error pendant wp_authenticate. Voici un exemple plus sélectif, à adapter avec prudence :
Add_filter('authenticate', function($user, $username, $password) // Si aucune erreur explicite n'est présente, on ne touche pas. If ($user instanceof WP_User) Return $user; // On ne change pas l'objet ici, on laisse login_errors gérer. // Cette fonction sert surtout à contrôler des cas spécifiques si besoin. Return $user; , 10, 3);Je montre ce squelette pour illustrer l’idée, pas pour vous pousser à l’utiliser tel quel. Modifier authenticate sans compréhension des cas peut casser des flux légitimes : compte verrouillé, mots de passe temporaires, ou intégrations 2FA.
Le bon réflexe, c’est de commencer par login_errors, observer le résultat sur plusieurs cas, puis seulement ensuite chercher d’autres points de fuite.
Vérifier ce que vous masquez vraiment (sans vous tromper de bataille)
Avant de conclure que “c’est réglé”, faites un test méthodique. Sur un site de développement, ou sur une copie de préprod, vous pouvez simuler des tentatives :
- identifiant vide, mot de passe vide identifiant saisi, mot de passe vide identifiant saisi, mot de passe invalide identifiant inexistant, mot de passe quelconque
Le but n’est pas seulement de regarder le texte. Regardez aussi la taille de la page, la présence d’erreurs côté HTML, et les redirections. Certains plugins de sécurité modifient l’expérience : par exemple ils peuvent afficher un bandeau, ou rediriger vers une page d’anti-bot. Dans ce cas, votre filtre peut être contourné.
Sur mes interventions, c’est très souvent la combinaison plugin + thème qui crée les écarts. L’installation semble “standard”, puis un plugin de sécurité modifie la traduction ou la sortie, et votre filtre ne touche pas tout.
Si vous observez une différence persistante entre “compte inexistant” et “mot de passe incorrect” dans le rendu, le texte n’est pas le seul vecteur. Il peut y avoir un log côté serveur que l’attaquant n’a pas, mais le temps de réponse peut varier. Là, on entre dans l’optimisation anti-enumération, et le bon remède devient plutôt le rate limiting et la normalisation de comportement, pas uniquement le texte.
Et la récupération de mot de passe, on fait quoi ?
Beaucoup de gens oublient que l’énumération peut aussi passer par la récupération de mot de passe. WordPress est conçu pour éviter de confirmer si un e-mail existe, en affichant souvent un message neutre du type “Si un compte correspond…”. C’est déjà un garde-fou utile.
Mais là encore, selon votre configuration, des variantes peuvent apparaître. Par exemple :
- message de plugin de sécurité plus précis que WordPress thème qui reformate la page traduction ou surcharge qui a introduit une nuance
Le bon réflexe est de tester au niveau de la page “mot de passe oublié”. Vous essayez avec un e-mail existant et un e-mail inexistant. Si vous voyez une différence visible, même légère, vous avez une piste.
Selon ce que vous constatez, la correction peut consister à restaurer le comportement WordPress par défaut, ou à ajuster un plugin qui surinterprète les erreurs.
Je préfère rester prudent ici : les points d’accroche exacts pour la récupération peuvent varier selon la version et selon la façon dont un plugin gère le flux. Plutôt que de vous donner un snippet “universel” qui risque de mal tomber, testez votre cas, puis adaptez en ciblant ce qui diverge chez vous.
Le rôle des plugins de sécurité : utile, mais attention au doublon
Il existe des plugins qui “masquent” déjà les erreurs de connexion ou qui normalisent les messages d’échec. Parfois ils font le job avec des réglages, parfois ils injectent des filtres dans WordPress.
Le piège, c’est le doublon. Si vous ajoutez votre propre code et que le plugin fait aussi le sien, vous pouvez vous retrouver avec :
- un message neutralisé une fois, puis remplacé par une autre variante une erreur neutre affichée, mais un autre élément (bandeau, tooltip, champ) révèle une différence un conflit de priorité sur les filtres, où votre code s’exécute avant ou après celui du plugin
Sur un site vivant, je recommande une https://gardewp.fr/securite-wordpress/ méthode simple : désactivez temporairement vos modifications, constatez le comportement d’origine, puis réactivez. Faites la comparaison proprement. Ce n’est pas glamour, mais ça évite de “paper security”, un terme que j’utilise quand on croit avoir corrigé, alors que seule l’interface a changé.
Ce que cette mesure ne résout pas
Cacher les erreurs d’identification rend l’attaque moins efficace, mais ce n’est pas une barrière totale. Un attaquant peut toujours :
- deviner par analyse externe (politiques de session, empreinte navigateur, collecte d’informations publiques) effectuer des attaques sans besoin d’un message utile exploiter d’autres vecteurs, comme des mots de passe faibles, des fuites ailleurs, ou des vulnérabilités non liées à l’authentification
Il faut donc voir cette mesure comme une couche. Une couche utile, surtout contre les scripts automatisés qui “lisent” les réponses, mais jamais suffisante.
Dans mes propres repasses de sécurité, la vraie différence se fait quand on combine “messages neutres” avec “limitation de tentatives” et “détection”. Sans ces éléments, un bot peut continuer à tester, et finir par trouver.
Plan d’action réaliste (et moins risqué pour votre site)
Si vous voulez faire ça proprement, sans casser l’authentification ni dégrader l’expérience, voici un chemin que j’ai vu fonctionner sur des environnements variés.
- Appliquez d’abord le filtre login_errors pour forcer un message unique. Testez quatre cas côté connexion et au moins deux cas côté récupération de mot de passe. Vérifiez l’interaction avec vos plugins de sécurité (surtout ceux qui modifient l’écran de connexion). Combinez avec un contrôle de tentatives (limitation, blocage temporaire, ou règles de pare-feu).
Cette séquence évite le “tout ou rien”. Vous gagnez du terrain rapidement, puis vous consolidez.
Optimiser la sécurité au-delà du texte : limiter l’impact réel
Une fois que les messages sont neutralisés, il reste le volet le plus efficace contre l’énumération automatisée : ralentir et tarir les tentatives répétées.
Sans entrer dans un catalogue, retenez l’idée suivante : plus une attaque coûte cher en temps et en nombre d’essais, moins elle est rentable. Les messages neutres réduisent l’information, mais les contrôles de débit réduisent la capacité.
Concrètement, vous pouvez compter sur plusieurs niveaux : règles serveur, pare-feu applicatif, restrictions IP temporaires, contrôles côté WordPress. L’approche exacte dépend de votre hébergement, de votre trafic, et des risques d’impact sur des utilisateurs légitimes (par exemple un employé qui change de mot de passe et s’y reprend à deux fois).
Le bon jugement ici, c’est d’anticiper les faux positifs. Un blocage trop agressif peut vous créer des appels au support, ou des interruptions internes. L’anti-enumération est une défense, pas une machine à frustration.
Un mot sur l’accessibilité et l’UX
Neutraliser les messages ne signifie pas effacer toute information pour vos utilisateurs.
Si vous affichez “Identifiants invalides.” de façon constante, cela peut suffire. Mais gardez une cohérence sur la forme : conserver des repères visuels, garder un style clair, ne pas supprimer les éléments de navigation utiles (lien “mot de passe oublié”, par exemple). Ce sont des micro-détails, et pourtant ils font la différence entre un utilisateur qui corrige son erreur et un utilisateur qui abandonne.
Autre point : si vous exploitez des systèmes de connexion personnalisés, ou si votre thème remplace le formulaire, votre filtre doit être réévalué. Le code WordPress agit sur un contenu standard, mais vos composants peuvent ne pas afficher la même variable.
Ce que je conseille pour finir, en pratique
Votre objectif n’est pas juste de “cacher”. Votre objectif est de rendre la tentative d’identification peu instructive, puis de rendre la répétition peu rentable.
Commencez simple avec login_errors. Faites le test comparatif entre différents cas. Si vous observez encore une différence exploitable, ciblez le flux précis (connexion, récupération de mot de passe, endpoint utilisé par vos plugins). Et surtout, combinez avec des garde-fous contre le volume.
Sur beaucoup de sites, ce petit ajustement a un effet immédiat et mesurable dans les journaux d’échec, pas forcément parce que les attaquants s’arrêtent, mais parce qu’ils perdent la capacité de “raisonner” à partir des messages. Ce détail change l’attaque, et c’est exactement ce que vous voulez quand vous cherchez à renforcer la sécurité WordPress sans créer de complexité inutile.
Si vous me donnez votre contexte (hébergement, plugins de sécurité présents, et ce que vous observez exactement dans le message entre deux scénarios), je peux vous proposer un réglage plus ciblé, avec un niveau de prudence adapté à votre installation.