Attaque brute force : qu'est-ce que c'est et comment s'en protéger sur WordPress

Qu'est-ce qu'une attaque brute force ?

Le terme vient de l'anglais brute force, « force brute » : on n'exploite aucune faille, on essaie. L'OWASP décrit l'attaque comme un procédé où « un attaquant configure des valeurs prédéterminées, envoie des requêtes au serveur avec ces valeurs, puis analyse la réponse ». Sur une page de connexion, un programme soumet des milliers de couples identifiant et mot de passe et retient ceux que le serveur accepte. Cybermalveillance.gouv.fr précise que ces attaques, « réalisées par des ordinateurs, peuvent tester des dizaines de milliers de combinaisons par seconde ».

En pratique, l'attaquant n'essaie pas toutes les combinaisons. Il utilise des listes : mots de passe les plus courants, mots du dictionnaire avec variantes, identifiants habituels et surtout mots de passe volés lors de fuites sur d'autres services. L'OWASP distingue trois techniques voisines.

Quant au « logiciel brute force » que beaucoup recherchent : il en existe des dizaines, libres et légitimes dans un cadre de test autorisé. Hydra, « un casseur de connexions parallélisé qui prend en charge de nombreux protocoles » selon ses auteurs, Burp Suite ou WPScan (énumération des utilisateurs et attaque par mot de passe) sont les plus cités. Les campagnes réelles viennent surtout de botnets qui balaient en continu des millions de sites WordPress.

Comment se déroule une attaque brute force sur WordPress

WordPress est une cible commode : page de connexion identique partout, comptes prévisibles, aucune limitation des tentatives dans le cœur. Quatre points d'entrée sont utilisés.

wp-login.php, la porte principale

Chaque tentative est une requête POST vers /wp-login.php avec les champs log et pwd, et rien ne ralentit un robot, à part la puissance du serveur. La documentation WordPress recommande de « limiter le débit sur wp-login.php et de l'isoler avec des règles de pare-feu ou de serveur », et précise que renommer la page « réduit le bruit mais ne doit pas être votre seule défense ».

xmlrpc.php et system.multicall, des centaines d'essais en une requête

Le fichier xmlrpc.php est l'ancienne interface de publication à distance, encore utilisée par Jetpack (« XML-RPC est un protocole que Jetpack utilise pour connecter votre site à WordPress.com ») et quelques applications mobiles. Il accepte des appels authentifiés par mot de passe, et sa méthode system.multicall regroupe plusieurs appels dans une seule requête HTTP. Sucuri a documenté dès octobre 2015 des attaques par amplification : « avec seulement 3 ou 4 requêtes HTTP, les attaquants pouvaient essayer des milliers de mots de passe », à l'insu des outils qui comptent les échecs sur wp-login.php. La documentation WordPress est sans détour : « si vous n'utilisez pas XML-RPC, désactivez-le ».

L'énumération des comptes par l'API REST et les archives d'auteur

Deviner le mot de passe est plus facile quand on connaît l'identifiant, et WordPress le révèle de deux façons. L'adresse /?author=1 redirige vers l'archive de l'auteur, dont l'URL contient en général son identifiant de connexion. L'API REST répond à /wp-json/wp/v2/users par la liste des utilisateurs (numéro, nom d'affichage, « slug »), limitée pour un visiteur non connecté aux comptes qui ont publié au moins un contenu, donc souvent l'administrateur. Notre guide pour sécuriser l'API REST de WordPress traite le sujet.

Les mots de passe d'application

Depuis WordPress 5.6, chaque utilisateur peut créer des mots de passe d'application (24 caractères, plus de 142 bits d'entropie) pour connecter un outil externe à l'API REST ou à XML-RPC. Ils ne servent pas sur le formulaire de connexion, mais une fois le mot de passe principal trouvé, l'attaquant peut s'en créer un pour garder un accès discret à l'API. Vérifiez la liste dans le profil de chaque administrateur, et désactivez la fonction si rien ne s'en sert :

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Comment reconnaître une attaque brute force

La plupart des sites en subissent en permanence sans le savoir. Les signes qui doivent alerter :

• un site lent ou des erreurs 503 : chaque tentative charge PHP, et un flot de requêtes sature un hébergement mutualisé ;
• des emails de verrouillage en rafale envoyés par Wordfence ou Limit Login Attempts, souvent sur un compte « admin » qui n'existe même pas ;
• un pic de requêtes vers xmlrpc.php ou wp-login.php dans les statistiques de l'hébergeur ;
• le pire des cas : un compte administrateur inconnu, ou votre mot de passe qui ne fonctionne plus. Il faut alors reprendre la main sur le compte avant toute chose.

Le journal d'accès du serveur (access.log chez Apache et nginx, « Raw Access » dans cPanel) apporte la preuve :

# Adresses IP qui envoient le plus de POST vers wp-login.php
grep "POST /wp-login.php" access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

# Requêtes vers xmlrpc.php, par jour
grep "xmlrpc.php" access.log | awk '{print substr($4,2,11)}' | sort | uniq -c

# Tentatives d'énumération des comptes
grep -E "author=[0-9]+|wp-json/wp/v2/users" access.log | wc -l

Plusieurs centaines de POST depuis une même adresse en quelques minutes ne laissent aucun doute.

Les protections contre la force brute, classées par efficacité

Du plus au moins efficace : les deux premières suffisent à empêcher l'intrusion, les suivantes protègent le serveur.

Un mot de passe long, unique, et un identifiant qui n'est pas « admin »

La CNIL, dans sa recommandation de 2022, fixe l'ordre de grandeur : au moins 12 caractères mêlant majuscules, minuscules, chiffres et caractères spéciaux, ou 14 caractères avec trois de ces catégories, ou une phrase de passe d'au moins sept mots ; un mot de passe par compte ; un renouvellement périodique exigé seulement pour les administrateurs. Pour l'identifiant, évitez « admin », le nom du domaine ou le prénom affiché sur les articles.

L'authentification à deux facteurs

Même avec le bon mot de passe, l'attaquant bute sur le code temporaire généré par une application ou reçu par email ; l'OWASP y voit la défense la plus efficace contre le bourrage d'identifiants. WordPress ne l'intègre pas (« le cœur de WordPress n'inclut pas la 2FA », rappelle sa documentation) : l'extension Two-Factor, maintenue par des contributeurs de WordPress.org et installée sur plus de 100 000 sites, propose codes TOTP, codes par email et codes de secours. Activez-la sur tous les comptes administrateur et éditeur ; notre comparatif sur l'authentification 2FA WordPress aide à choisir.

Limiter les tentatives de connexion

Après plusieurs échecs, l'adresse IP ou le compte est bloqué pendant un délai croissant : la « temporisation d'accès au compte après plusieurs échecs » que cite la CNIL. Limit Login Attempts Reloaded (plus d'un million d'installations) et Wordfence le font depuis l'extension ; la documentation WordPress préfère une limitation au niveau du serveur ou du pare-feu, car une extension « consomme des ressources sous une attaque intense ».

Désactiver ou restreindre xmlrpc.php

Si ni Jetpack, ni l'application mobile WordPress, ni un outil de publication à distance ne l'utilisent, fermez la porte dans le fichier .htaccess d'Apache :

<Files xmlrpc.php>
    Require all denied
</Files>

Ou, côté WordPress, avec le filtre qui refuse les méthodes XML-RPC nécessitant une authentification (introduit dans la version 3.5) :

add_filter( 'xmlrpc_enabled', '__return_false' );

Si Jetpack est indispensable, faites plutôt bloquer system.multicall par le pare-feu.

Protéger ou déplacer wp-login.php

Renommer l'URL de connexion arrête les robots qui frappent à l'adresse standard, pas un attaquant qui vous vise. Une protection par mot de passe HTTP sur la seule page wp-login.php est plus solide, mais la documentation WordPress déconseille de l'étendre à tout /wp-admin/ : cela « casse les extensions basées sur AJAX ». La restriction par adresse IP reste la plus simple quand l'équipe a des adresses fixes ; voir notre guide pour sécuriser wp-login.php.

fail2ban sur le serveur

Sur un VPS ou un serveur dédié, fail2ban lit les journaux et bannit au niveau du pare-feu système les adresses qui accumulent les échecs, avant qu'elles n'atteignent PHP. L'extension WP fail2ban (60 000 installations) écrit échecs de connexion, énumérations et abus de XML-RPC dans le journal système, avec trois filtres prêts à l'emploi (wordpress-hard.conf, wordpress-soft.conf, wordpress-extra.conf). Notre tutoriel fail2ban pour WordPress donne la configuration.

Cloudflare : limitation de débit et défi géré

Placer Cloudflare devant le site déplace le filtrage hors du serveur. Ses règles de limitation de débit s'appliquent aux requêtes qui correspondent à une expression, avec une action au choix (blocage, défi géré) ; le plan gratuit en inclut une, avec une période de comptage limitée à 10 secondes. Une règle typique :

(http.request.uri.path eq "/wp-login.php" and http.request.method eq "POST")
# Compter par adresse IP ; seuil : 5 requêtes en 10 secondes ; action : Managed Challenge

La même logique s'applique à /xmlrpc.php. Notre article sur Cloudflare face aux attaques WordPress décrit aussi les règles WAF et le mode « sous attaque ».

Bloquer l'énumération des comptes

Empêcher la découverte des identifiants retire à l'attaquant la moitié de l'équation. Ce mu-plugin cache la liste des utilisateurs de l'API REST aux visiteurs non connectés :

<?php
// wp-content/mu-plugins/masquer-utilisateurs-rest.php
add_filter( 'rest_endpoints', function ( $endpoints ) {
    if ( ! is_user_logged_in() ) {
        unset( $endpoints['/wp/v2/users'], $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
    }
    return $endpoints;
} );

Complétez par le refus des requêtes ?author=N aux visiteurs anonymes et par le filtre login_errors, qui rend le message d'échec identique que l'identifiant existe ou non.

Tableau comparatif des protections

Protection	Ce qu'elle empêche	Efficacité	Difficulté	Effets de bord
Mot de passe long et unique	La réussite de l'attaque	Très élevée	Nulle	Aucun avec un gestionnaire
Authentification à deux facteurs	L'intrusion, même avec le bon mot de passe	Très élevée	Faible	Codes de secours à conserver
Limitation des tentatives (extension)	Les essais en série depuis une IP	Élevée contre les robots simples	Faible	Charge PHP conservée ; contournable par botnet
Désactivation de xmlrpc.php	L'amplification par system.multicall	Élevée	Faible	Casse Jetpack et l'application mobile
Restriction IP ou mot de passe HTTP sur wp-login.php	Tout accès au formulaire hors de l'équipe	Très élevée	Moyenne	Inadaptée aux équipes nomades
Renommage de wp-login.php	Les robots qui visent l'URL standard	Faible à moyenne	Faible	Sécurité par l'obscurité
fail2ban	Les IP récidivistes, avant PHP	Élevée	Moyenne, accès serveur requis	Indisponible en mutualisé
Cloudflare, limitation de débit et WAF	Le flot de requêtes, avant le serveur	Élevée	Moyenne	Fenêtre de 10 secondes en plan gratuit
Blocage de l'énumération	La découverte des identifiants	Moyenne	Faible	Aucun

Et si le mot de passe a déjà été trouvé ?

Une attaque réussie ne laisse pas toujours de trace : l'attaquant se connecte, crée un second compte administrateur ou un mot de passe d'application, dépose une porte dérobée, puis se déconnecte. Au moindre doute, changez tous les mots de passe (WordPress, hébergement, base de données, SFTP), révoquez les mots de passe d'application, puis passez le site au crible comme s'il était infecté. La force brute est aussi le complément habituel d'une faille de sécurité dans une extension : le compte volé sert à exploiter une fonction réservée aux utilisateurs connectés. Si vous préférez déléguer, notre équipe établit un diagnostic gratuit sous 12 heures, et notre formule Assurance et maintenance est à 50 € par mois.

Sources

• Brute Force Attacks, WordPress Developer Resources, 25 février 2026
• Brute Force Amplification Attacks Against WordPress XMLRPC, Sucuri (Daniel Cid), 8 octobre 2015
• Application Passwords: Integration Guide, Make WordPress Core, 5 novembre 2020
• Hook xmlrpc_enabled, REST API Reference, Users et class-wp-rest-users-controller.php, WordPress, consultés le 6 septembre 2026
• Jetpack and XML-RPC, Jetpack Support
• Brute force attack et Credential Stuffing Prevention Cheat Sheet, OWASP
• Mots de passe : une nouvelle recommandation pour maîtriser sa sécurité, CNIL, 14 octobre 2022
• Pourquoi et comment bien gérer ses mots de passe ?, Cybermalveillance.gouv.fr, 12 mai 2026
• Rate limiting rules, Cloudflare Docs
• Hydra, Kali Linux Tools ; WPScan, dépôt GitHub
• Fiches WordPress.org : Two-Factor, Limit Login Attempts Reloaded, WP fail2ban, Wordfence Security, 6 septembre 2026