WordPress n'impose aucune limite au nombre d'essais de mot de passe : un robot peut en tenter autant que le serveur en accepte. Limiter les tentatives est donc l'une des premières protections ajoutées à un site. Mal réglée, elle bloque pourtant vos propres utilisateurs, ou ne bloque rien du tout derrière un CDN. Voici les réglages qui comptent et les pièges les plus fréquents.
Définition express : Attaque par force brute. Solution prête à l’emploi : Protection anti brute force WordPress avec WP Masquerade.
Le principe et ses trois réglages
L'aide-mémoire Authentification de l'OWASP décrit trois paramètres :
- le seuil : le nombre d'échecs tolérés ;
- la fenêtre d'observation : la période pendant laquelle ces échecs sont comptés ;
- la durée de blocage : combien de temps la connexion reste refusée une fois le seuil atteint.
Certaines applications utilisent un blocage exponentiel : une durée très courte au départ, qui double à chaque nouveau blocage. Cela gêne peu un humain qui se trompe deux fois, mais ralentit fortement un robot.
Quels chiffres choisir
Il n'existe pas de valeur officielle universelle. Les repères disponibles :
- le NIST (SP 800-63B-4) impose aux vérificateurs de limiter les échecs consécutifs sur un même authentifiant à 100 au maximum, en précisant que c'est une borne haute et que des limites plus basses sont possibles ;
- l'OWASP insiste sur l'équilibre entre protection et risque de blocage des utilisateurs légitimes ;
- à titre de comparaison, WP Masquerade Pro autorise par défaut 8 échecs, puis bloque l'adresse 15 minutes.
| Type de site | Seuil | Durée de blocage | Remarque |
|---|---|---|---|
| Site vitrine, un ou deux administrateurs | 5 à 8 échecs en 15 minutes | 15 à 60 minutes | Peu de faux positifs possibles |
| Site de rédaction multi-auteurs | 8 à 10 échecs | 15 à 30 minutes | Prévoir le déblocage par un administrateur |
| Boutique ou espace membres | 10 à 20 échecs | 5 à 15 minutes, exponentielle | Les clients oublient souvent leur mot de passe |
| Tout site | Double authentification pour les administrateurs | Sans objet | Rend le seuil moins critique |
Ces valeurs sont un point de départ éditorial, pas une norme : observez combien d'échecs légitimes apparaissent dans vos journaux avant de serrer.
Compter par adresse IP ou par compte ?
C'est le choix le plus important, et chacun a un défaut.
| Méthode | Ce qu'elle arrête | Son point faible |
|---|---|---|
| Par adresse IP | Un robot qui insiste depuis une même adresse | Un botnet change d'adresse ; une adresse partagée bloque des innocents |
| Par compte (identifiant) | Les essais répartis sur des milliers d'adresses contre un même compte | Un inconnu peut bloquer volontairement un utilisateur légitime |
| Les deux, avec double authentification | La grande majorité des cas | Réglages un peu plus complexes |
L'OWASP recommande d'associer le compteur au compte pour contrer les attaques venant de nombreuses adresses, tout en mettant en garde contre le risque inverse : permettre à un attaquant de bloquer d'autres utilisateurs. Elle suggère par exemple de laisser fonctionner le lien « Mot de passe oublié » même lorsqu'un compte est bloqué.
La plupart des extensions WordPress comptent par adresse IP. C'est efficace contre les robots insistants, mais la documentation WordPress le rappelle : ces attaques viennent souvent de botnets, donc d'adresses très nombreuses. Le rapport 2024 de Wordfence évoque près de 136 millions d'adresses distinctes à l'origine d'attaques sur les mots de passe dans l'année. La plupart des extensions de sécurité généralistes intègrent aussi une limitation des connexions : notre comparatif des meilleurs plugins de sécurité WordPress indique lesquelles.
Le piège des proxys et des CDN
Quand un CDN comme Cloudflare est placé devant votre site, ce n'est plus le visiteur qui contacte votre serveur, c'est le CDN. Pour PHP, l'adresse de connexion (REMOTE_ADDR) est alors celle du CDN.
Deux erreurs opposées sont possibles :
- compter l'adresse du CDN : tous les visiteurs semblent venir de quelques adresses. Les échecs d'un robot bloquent alors vos utilisateurs, ou le blocage est si large qu'il devient inutilisable ;
- croire l'en-tête
X-Forwarded-Forsans vérification : cet en-tête est envoyé par le client et peut être falsifié. Un robot qui envoie une adresse différente à chaque requête échappe à tout comptage.
La bonne méthode est de restaurer l'adresse réelle au niveau du serveur. Cloudflare documente cette configuration : module mod_remoteip pour Apache avec l'en-tête CF-Connecting-IP, ou module realip pour Nginx, en déclarant uniquement les plages d'adresses de Cloudflare comme proxys de confiance. Cloudflare précise que ces plages évoluent et doivent être tenues à jour. Une fois cela fait, REMOTE_ADDR contient l'adresse du visiteur et toutes les extensions en profitent.
Les adresses partagées
Même sans CDN, une adresse IP ne correspond pas toujours à une personne.
- Réseaux d'entreprise, écoles, wifi publics : des dizaines ou des centaines de personnes sortent par la même adresse.
- Opérateurs mobiles : beaucoup utilisent un NAT à grande échelle (CGN), pour lequel l'IETF a réservé un bloc d'adresses dédié (RFC 6598). Un même client peut changer d'adresse et partager la sienne avec d'autres abonnés.
- IPv6 : un abonné reçoit généralement un bloc entier d'adresses (la RFC 6177 recommande d'attribuer à chaque site au moins un /64, et souvent bien plus). Compter adresse par adresse en IPv6 laisse un robot en essayer des milliers sans jamais atteindre le seuil ; il est plus pertinent de compter par préfixe.
Conséquences pratiques : gardez une liste d'adresses de confiance pour vos bureaux, ne bloquez pas définitivement une adresse, et prévoyez un moyen simple pour un administrateur de se débloquer.
Faux positifs : à quoi s'attendre
- Un utilisateur qui a changé son mot de passe et dont le navigateur ou l'application mobile renvoie l'ancien en boucle.
- Une application ou un service qui se connecte à XML-RPC ou à l'API REST avec un mot de passe périmé.
- Un client de boutique qui essaie tous ses mots de passe habituels.
- Un administrateur derrière la même adresse qu'un poste infecté du réseau.
Pour chacun, la double authentification et les mots de passe d'application réduisent le besoin d'un seuil très bas.
Avec WP Masquerade
WP Masquerade Pro intègre la limitation des tentatives de connexion par adresse réseau : 8 échecs autorisés par défaut, réglable de 3 à 30, avec une durée de blocage de 15 minutes par défaut, réglable de 1 à 60. Une connexion réussie remet le compteur à zéro, et l'onglet de dépannage permet de débloquer votre propre adresse. L'extension compte l'adresse de connexion du serveur et ne fait jamais confiance à un en-tête X-Forwarded-For envoyé par le client : derrière un CDN, la restauration de l'adresse réelle doit donc être faite au niveau du serveur, comme décrit plus haut. Les échecs de double authentification comptent aussi dans cette limitation. Son guide le précise : ce n'est ni une limitation de trafic réseau ni une défense suffisante seule contre une attaque distribuée.
À retenir
- WordPress ne limite pas nativement les essais de connexion.
- Réglez trois paramètres : seuil, fenêtre d'observation, durée de blocage ; préférez des blocages courts ou exponentiels.
- Derrière Cloudflare ou un autre CDN, restaurez l'adresse réelle au niveau du serveur et ne croyez jamais
X-Forwarded-Forsans vérification. - Une adresse IP peut être partagée par des centaines de personnes ; en IPv6, comptez par préfixe.
- La limitation ralentit les robots ; la double authentification protège le compte.
Sources
- OWASP : Authentication Cheat Sheet (Account Lockout) (nouvel onglet)
- NIST SP 800-63B-4 : Authentication and Authenticator Management (limitation des essais) (nouvel onglet)
- WordPress Developer Resources : Brute Force Attacks (nouvel onglet)
- Cloudflare : Restoring original visitor IPs (nouvel onglet)
Autres sources consultées : documentation officielle et base Wordfence.
