Aller au contenu principal
Les AI Overviews sont déployés en France depuis le 22 juillet 2026
Sécurité WordPress Lecture 6 min

Attaque par force brute

Une attaque par force brute est une série d'essais automatisés de couples identifiant et mot de passe jusqu'à ce que l'un fonctionne.

Définition

Une attaque par force brute est une série d’essais automatisés de mots de passe jusqu’à ce que l’un fonctionne. Elle ne cherche aucune faille dans le code : elle mise sur un mot de passe devinable et sur une page de connexion qui accepte un nombre illimité d’essais.

01Rien n’est piraté au sens technique : c’est une porte que l’on essaie d’ouvrir avec toutes les clés.
02Les tentatives sont automatiques et permanentes, elles ne visent personne en particulier.
03Le blocage par adresse arrive trop tard : les essais viennent de dizaines de machines différentes.

Comment se déroule une attaque par force brute ?

Un programme envoie des couples identifiant et mot de passe à la page de connexion, en boucle.

La documentation de WordPress la décrit comme la manière la plus simple d’entrer : un attaquant essaie des combinaisons jusqu’à ce que l’une fonctionne. Rien d’artisanal là-dedans. Les essais partent de machines infectées réparties dans le monde, un même réseau pouvant viser des milliers de sites la même nuit. Les listes employées ne sont pas aléatoires : ce sont des mots de passe issus de fuites publiques, classés par fréquence, et les identifiants les plus courants, à commencer par admin et par le nom de domaine.

La page de connexion n’est pas la seule porte. Le fichier d’appels distants de WordPress, xmlrpc.php, accepte lui aussi des identifiants, et permettait historiquement d’essayer plusieurs mots de passe dans une seule requête. C’est pourquoi la documentation officielle recommande de restreindre ou de désactiver ce fichier au même titre que wp-login.php.

Pourquoi un petit site est-il visé ?

Parce qu’il n’est pas choisi. Il est trouvé.

Un site de dix pages sans trafic reçoit les mêmes tentatives qu’un site de mille pages, pour une raison simple : les robots parcourent des listes d’adresses, pas des classements de notoriété. Ce que cherche l’attaquant n’est pas votre clientèle, c’est un serveur utilisable. Un site WordPress compromis sert à envoyer du courrier indésirable, à héberger des pages de contrefaçon ou à relayer d’autres attaques, et sa valeur ne dépend pas de son audience.

Le volume compte même quand l’attaque échoue. Chaque essai déclenche PHP et une requête à la base de données. Sur un hébergement mutualisé où le nombre de processus est limité, une rafale suffit à ralentir le site pour les visiteurs réels, sans qu’aucun mot de passe n’ait été trouvé.

Que faire pour la rendre inefficace ?

Quatre mesures, dans cet ordre d’efficacité.

01

Un mot de passe long et unique

C’est la seule mesure qui rend l’attaque mathématiquement inutile. Long, propre à ce site, conservé dans un gestionnaire de mots de passe. Un mot de passe réutilisé ailleurs est déjà dans les listes. Si l’attaque a déjà abouti, changer les mots de passe ne suffit plus : il faut vérifier ce qui a été déposé sur le site.

02

La double authentification

La documentation WordPress la recommande explicitement pour tous les comptes administrateurs. Même trouvé, le mot de passe ne suffit plus à entrer.

03

Une limite au nombre d’essais

Limiter la cadence des tentatives, si possible en amont du site, sur le pare-feu ou le service de diffusion. L’objectif n’est pas de bloquer une adresse, c’est de rendre le coût de l’attaque supérieur à son gain.

04

Fermer les portes secondaires

Restreindre xmlrpc.php, masquer la page de connexion pour supprimer le bruit, et supprimer le compte nommé admin s’il existe encore. Ces gestes retirent les cibles les plus rentables.

Comment détecter une attaque, et que faire si elle réussit ?

La détection se lit dans les journaux, la réaction ne se limite pas au mot de passe.

Trois signes se vérifient sans outil particulier. Des échecs de connexion répétés sur une courte période, visibles dans les journaux du serveur ou rapportés par une extension de sécurité. Un site qui ralentit sans hausse de fréquentation, parce que chaque essai déclenche PHP et la base de données. Et des courriels de réinitialisation de mot de passe que personne n’a demandés, signe qu’un identifiant valide a été repéré.

Si un compte a effectivement été deviné, changer le mot de passe ne suffit pas. La documentation de WordPress est explicite sur ce point : un site où quelqu’un est entré doit être traité comme compromis. Cela veut dire chercher les comptes administrateurs inconnus, les fichiers déposés, les tâches planifiées ajoutées, puis renouveler tous les accès et les clés de sécurité du fichier de configuration. C’est la matière des fiches nettoyage d’un site infecté et restauration après piratage.

Ce que cela donne sur un site réel

Mesure du 4 septembre 2026, sur un mois de journaux d’un site vitrine WordPress d’une trentaine de pages. Au mois d’août, le serveur a reçu 386 requêtes sur l’adresse de connexion par défaut, dont 75 en envoi de formulaire, depuis 90 adresses distinctes, et sur les 31 jours du mois sans exception. La répartition est instructive : deux adresses concentrent 234 tentatives à elles seules, les 88 autres en font moins de huit chacune. Le fichier d’appels distants a reçu 120 requêtes de plus, et 403 requêtes ont cherché à lister les comptes du site. Rapporté aux 45 810 requêtes du mois, ce bruit reste minoritaire, mais il est quotidien et entièrement automatique. Aucun de ces essais n’a obtenu de page de connexion, pour une raison expliquée dans la fiche voisine.

Questions fréquentes

Comment savoir si mon site est visé ?

Par les journaux du serveur, qui enregistrent chaque requête reçue, ou par une extension de sécurité qui rapporte les échecs de connexion. L’absence d’alerte ne signifie rien : sans outil de mesure, les tentatives passent inaperçues.

Faut-il bloquer les adresses qui insistent ?

Cela soulage, mais ne protège pas : les tentatives suivantes viennent d’autres machines. Le blocage est un traitement du symptôme, le mot de passe et la double authentification traitent la cause.

Une attaque réussie se voit-elle tout de suite ?

Rarement. Un accès obtenu sert le plus souvent à déposer un fichier discret et à attendre. C’est pourquoi un site dont un compte a été deviné doit être traité comme compromis, et pas seulement voir son mot de passe changé.

Un site sans visiteurs est-il moins exposé ?

Non. Les robots travaillent sur des listes d’adresses, l’audience n’entre pas dans leur choix. Un site neuf reçoit des tentatives dès sa mise en ligne.

Sources

Et sur votre site ?

Une définition ne dit pas si vous êtes concerné.

L'audit gratuit répond dans votre cas : état technique, temps de chargement, et ce que Google voit réellement de vos pages. Un constat écrit, sans engagement et sans jargon.