Audit de sécurité WordPress : la méthode que j’applique en mission

Votre site s’est fait pirater, une sauvegarde a été restaurée, tout refonctionne. Affaire classée ? C’est ce qu’on croit, et je comprends pourquoi. À l’écran, plus rien ne cloche : les pages s’affichent, les commandes repartent, le client respire. Sauf qu’une restauration remet en ligne le site d’AVANT le piratage. Avec sa faille d’origine, ses comptes douteux, ses fichiers oubliés…

Une restauration remet le site debout. Elle ne le nettoie pas. Et c’est exactement le rôle d’un audit de sécurité WordPress : vérifier, preuves à l’appui, ce que la restauration n’a pas réglé, puis lister ce qui reste ouvert.

Je vais vous montrer ma méthode, celle que j’applique en mission sur les sites de mes clients. Les 5 axes, les commandes exactes, une checklist de 10 points à dérouler ce soir, et un cas réel (anonymisé) qui montre ce qu’on trouve vraiment dedans. Accrochez-vous, il y a de la matière.

Le site était "réparé". J’ai audité quand même

Fin janvier 2026, une boutique WooCommerce se fait pirater. Un script malveillant injecté au niveau du serveur, avant même le DOCTYPE de la page. Le prestataire de l’époque restaure une sauvegarde saine, le script disparaît, le site revit. Dossier clos, en apparence.

J’interviens un mois et demi plus tard pour l’audit, en lecture seule. Je ne modifie rien, je constate. Premier réflexe, toujours le même : la table des utilisateurs.

4 227 comptes. Dont 1 295 créés depuis le 1er janvier. Des noms truffés de points pour tromper les filtres (du genre rob.ert.qu.ick.jr), des adresses jetables en pagaille, et même des emails en .mil et .gov usurpés. Pendant que je lisais la base, le compteur tournait encore : l’attaque de spam était toujours en cours. Six semaines après le "nettoyage"… Six semaines.

Le plus beau ? Un anti-spam était installé sur le site. Désactivé. Il regardait passer les inscriptions, les bras croisés.

En creusant, j’ai déroulé le reste de la pelote. Les clés de sécurité (les fameux salts de wp-config.php) jamais régénérées depuis le piratage : toute session volée par l’attaquant restait donc valide, sur une boutique qui encaissait des commandes tous les jours.

Et le reste à l’avenant… Un phpinfo.php et un script de scan de base de données oubliés à la racine, accessibles publiquement. Les identifiants d’une API marketplace écrits en dur dans un mu-plugin. 57 extensions installées dont 12 inactives. Un wp-config.php lisible en 644. Et un mot de passe d’application actif sur un compte de test dont plus personne ne se souvenait.

Le site n’était pas compromis. Il était juste grand ouvert pour le prochain.

Et pourtant, tenez-vous bien : aucune backdoor, aucun webshell, aucun code injecté dans la base. La restauration avait fait son travail. Le problème n’était pas ce qui restait du hack, c’était tout ce qu’il avait laissé grand ouvert derrière lui.

Ah, et le détail que j’adore raconter… Le serveur m’a banni au bout de cinq tentatives SSH pendant l’audit. La seule protection qui fonctionnait vraiment ce jour-là, c’est moi qui l’ai déclenchée. 0_o

Un mois de travail plus tard, le risque global de cette boutique est passé de HAUT à BAS. 16 points corrigés. On y revient à la fin, chiffres en main, parce que la vraie leçon de ce chantier n’est pas technique. Elle est méthodologique.

Pourquoi restaurer un backup ne nettoie pas un piratage ?

Restaurer une sauvegarde après un piratage remet en ligne les fichiers et la base d’une date antérieure : le code malveillant visible disparaît, mais la vulnérabilité d’origine, les comptes créés par l’attaquant, les sessions actives et les accès annexes (FTP, API, mots de passe d’application) restent intacts. Sans audit derrière, le site redevient piratable à l’identique, par la même porte.

C’est toute la différence entre remettre le site debout et le sécuriser. La restauration efface les symptômes visibles. L’audit cherche la cause et referme les portes. Deux gestes distincts qu’on confond en permanence, et cette confusion coûte cher.

Les chiffres n’aident pas à dormir. Le rapport Patchstack 2026 recense 11 334 nouvelles failles WordPress découvertes en 2025, en hausse de 42 % sur un an, dont 91 % logées dans les extensions. WordPress lui-même (le core) n’en concentre que 6, toutes de basse priorité. Le risque n’est presque jamais dans WordPress : il est dans ce qu’on lui greffe.

Alors, à quoi sert un audit si on ne peut pas tout patcher ? À réduire la surface. Moins d’extensions, moins de comptes, moins de portes ouvertes, moins de fenêtres de tir pour l’attaquant. Un audit ne rend pas un site inviolable (ça n’existe pas), il le rend nettement moins intéressant à attaquer que le voisin. Et sur le web, être moins facile que le voisin, c’est déjà 90 % du travail.

Comment auditer WordPress en 5 axes, du plus exposé au plus discret ?

Chaque audit que je livre suit les mêmes 5 axes, dans le même ordre. Pas par manie de process : parce que cet ordre va de ce que l’attaquant voit en premier vers ce que personne ne regarde jamais. On commence par la vitrine, on finit par la cave.

Axe 1 : la surface d’attaque

Tout ce qu’un inconnu peut atteindre sans mot de passe. C’est le premier réflexe, parce que c’est le premier réflexe de l’attaquant. Trois choses à tester.

D’abord, l’énumération des utilisateurs via l’API REST. Ouvrez cette URL sur votre domaine :

https://votre-site.fr/wp-json/wp/v2/users

Un site correctement durci renvoie une erreur (401) ou une liste vide. Un site exposé, lui, vous crache la liste de ses comptes avec les identifiants de connexion (le champ slug)… et l’attaquant n’a plus qu’à s’occuper des mots de passe. Même test avec /?author=1, qui redirige vers l’auteur numéro 1 et révèle son login si l’énumération n’est pas bloquée.

Ensuite, les fichiers qui traînent. phpinfo.php, une sauvegarde .sql ou .zip laissée à la racine, un dossier /.git exposé, un fichier debug.log lisible. Chacun est une fuite d’information servie sur un plateau. Sur la boutique de tout à l’heure, le script de scan oublié à la racine chargeait wp-load.php et exécutait des requêtes SQL. En accès public. Arghhhh.

Enfin, les en-têtes HTTP de sécurité. Je termine cet axe en regardant la réponse du serveur :

curl -sI https://votre-site.fr | grep -i "x-frame\|x-content\|referrer\|strict-transport"

Je cherche X-Content-Type-Options, X-Frame-Options, Referrer-Policy et Strict-Transport-Security. Trente secondes de vérification, et leur absence en dit long sur le niveau d’entretien général : un site sans en-têtes de sécurité est presque toujours un site sans personne aux commandes.

Axe 2 : les extensions et le thème

91 % des failles WordPress viennent des extensions. L’inventaire est donc le coeur de l’audit, pas une formalité. Pour chaque extension, je pose trois questions : est-elle à jour, est-elle encore maintenue, sert-elle encore à quelque chose ?

La mise à jour se vérifie en une commande WP-CLI…

wp plugin list --update=available --fields=name,version,update_version

Elle liste les extensions en retard, avec la version installée et la version disponible. Zéro retard toléré sur les extensions de sécurité elles-mêmes : un pare-feu pas à jour, c’est un garde du corps qui dort. Les extensions inactives, elles, partent à la poubelle sans état d’âme :

wp plugin list --status=inactive --fields=name,version

Une extension désactivée reste du code exécutable sur votre serveur. Elle peut contenir une faille, être appelée directement par son URL, servir de point d’entrée. 12 sur 57 dans mon cas réel, dont des outils de migration à usage unique installés des années plus tôt et jamais retirés. Désactiver ne suffit pas. On désinstalle.

Reste la question qui fâche : cette extension est-elle fiable ? Pour y répondre, il faut croiser les failles connues, le rythme de maintenance et la réputation. J’ai construit un outil qui fait exactement ce croisement, gratuitement.

Mon vérificateur de plugins note chaque extension sur 100 en croisant l’API wordpress.org et les bases de vulnérabilités CVE. Sécurité sur 35, maintenance sur 30, communauté sur 20, support sur 15, plus les drapeaux rouges et les alternatives quand le score est critique. Vous tapez le nom d’une extension, vous avez son bulletin de santé en cinq secondes.

Axe 3 : les comptes et les rôles

Qui peut encore se connecter à votre site ? Répondez sans regarder… difficile, hein ? C’est pourtant l’axe le plus rentable de l’audit, et le plus négligé. Je liste les administrateurs :

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Puis je demande au client de justifier chaque nom, un par un. L’ancien prestataire parti en 2023. Le stagiaire de l’été dernier. Le compte de test avec son mot de passe d’application encore actif. Sur la boutique auditée, 3 des 4 administrateurs n’avaient plus aucune raison d’exister. Leurs contenus ont été réassignés, les comptes supprimés.

Le mot de passe d’application mérite une attention à part. C’est un accès permanent à l’API REST, distinct du mot de passe principal, qui survit à un changement de mot de passe classique. Un compte oublié avec un mot de passe d’application actif, c’est une clé de la maison confiée à quelqu’un dont vous ne connaissez même plus le visage.

Le principe tient en une phrase : un compte égale une personne vivante, identifiée, avec le rôle minimum dont elle a besoin. Un rédacteur n’a pas à être administrateur. Tout ce qui dépasse ce principe se supprime ou se rétrograde. Ni une, ni deux.

Axe 4 : l’intégrité du core et de la configuration

Voici LE test qui répond à la vraie question après un piratage : les fichiers de WordPress ont-ils été modifiés ?

wp core verify-checksums

Cette commande compare chaque fichier du core aux sommes de contrôle officielles de wordpress.org. Sur un site sain, elle répond "Success: WordPress installation verifies against checksums". Sur un site compromis, elle liste les fichiers modifiés ou ajoutés :

Warning: File doesn't verify against checksum: wp-admin/includes/class-x.php
Warning: File should not exist: wp-content/uploads/2025/img.php

Un fichier .php dans le dossier uploads, c’est presque toujours une backdoor. Le hic : verify-checksums est impossible à lancer quand WP-CLI n’est pas installé sur le serveur, ce qui arrive souvent en mutualisé. Sur ma boutique, WP-CLI était absent, et je l’ai signalé comme angle mort assumé de l’audit initial. Un audit honnête dit aussi ce qu’il n’a pas pu vérifier.

Côté configuration, quatre points dans wp-config.php méritent qu’on s’y arrête. Je les passe en revue à chaque audit :

• DISALLOW_FILE_EDIT à true. Sans cette constante, n’importe quel administrateur (ou quiconque a pris son compte) peut éditer du PHP directement depuis le tableau de bord. Un boulevard pour injecter une backdoor.
• Les permissions du fichier en 600 plutôt qu’en 644. wp-config.php contient vos identifiants de base de données : il n’a aucune raison d’être lisible par les autres comptes du serveur.
• Des salts récents. Après le moindre incident, on les régénère (voir plus bas). Des salts qui datent du piratage, autant tendre la clé sous le paillasson.
• Aucun identifiant tiers en dur. Une clé d’API stockée en clair dans un fichier lisible vaut tous les mots de passe du monde. On l’oublie trop souvent.

Axe 5 : les logs et les signaux faibles

Le dernier axe ne cherche pas des failles. Il cherche des symptômes. Ce sont eux qui trahissent une attaque en cours, quand tout le reste paraît normal.

Un pic d’inscriptions (les 1 295 comptes en dix semaines, personne n’avait tiqué). Des sessions e-commerce qui s’empilent sans jamais expirer : sur cette même boutique, j’ai purgé 138 110 sessions zombies qui alourdissaient la base à chaque page chargée. Des tâches planifiées inconnues, qu’on déterre avec :

wp cron event list

Une tâche cron que vous ne reconnaissez pas peut être une porte dérobée qui se réactive toute seule. Et puis les fichiers modifiés à des dates où personne ne travaillait, un dimanche à 3 h du matin.

Franchement, vous les liriez, vous, 4 000 lignes de logs ? Personne ne le fait. C’est bien pour ça que cet axe ne se subit pas, il se prépare : journalisation activée en amont, alertes automatiques sur les inscriptions et les connexions administrateur, et un tour de contrôle de dix minutes chaque mois. Dix minutes par mois valent mieux qu’une archéologie de deux jours une fois que le mal est fait.

Quels outils pour auditer la sécurité de WordPress ?

Ma boîte à outils d’audit est plus courte qu’on l’imagine. Pas de suite à 300 euros par an : quatre outils, dont trois gratuits, bien utilisés.

• WP-CLI, en ligne de commande : verify-checksums, plugin list, config shuffle-salts, cron event list. Le couteau suisse qui répond en secondes à ce qu’un scanner met une heure à deviner.
• Site Health (Outils, Santé du site) : le point de départ natif de WordPress, sous-estimé. Je détaille ce qu’il révèle et surtout ce qu’il cache dans mon guide de l’état de santé du site WordPress.
• La base WPScan : des dizaines de milliers de vulnérabilités WordPress cataloguées, consultables par version. La référence pour savoir si une faille précise vous concerne.
• Un scanner de fichiers comme Wordfence : utile pour détecter les signatures de code malveillant connues, à condition de connaître ses limites.

Parce que oui, le scanner a ses angles morts. Il n’a jamais vu le compte administrateur de l’ancien prestataire, ni les identifiants en dur dans le mu-plugin, ni l’anti-spam désactivé. Aucune signature ne détecte une négligence.

Je martèle cette limite depuis que je cocrée des extensions de sécurité (WPS Hide Login dépasse les 2 millions d’installations actives, et j’ai créé Login Armor contre le bourrage d’identifiants). Ce qui remonte dans les journaux d’attaques de ces plugins, ce ne sont pas des exploits sophistiqués. Ce sont des portes laissées ouvertes. Le scanner reste un thermomètre : indispensable, et incapable de soigner.

Pour la partie surveillance, celle qui prend le relais entre deux audits, j’ai mis en ligne un second outil gratuit.

Ma veille sécurité WordPress fonctionne depuis l’extérieur, sans rien installer : vous entrez votre URL, l’outil détecte vos extensions et votre thème, puis vous alerte par email dès qu’une faille les concerne. Quelle faille, quelle sévérité, quoi faire. Pas un bulletin générique que vous ne lirez jamais, uniquement ce qui touche VOTRE site.

La checklist express : 10 vérifications en 30 minutes

Pas de WP-CLI sous la main, ni deux jours devant vous. Voici la version condensée de ma méthode, à dérouler telle quelle. Chaque point se vérifie en une à cinq minutes, et couvre l’essentiel du risque courant.

1. Comptes administrateurs : listez-les, supprimez ou rétrogradez tout compte non justifiable, réassignez les contenus avant suppression.
2. Mots de passe d’application : dans le profil de chaque utilisateur, révoquez ceux que personne ne réclame.
3. Mises à jour : core, extensions, thèmes. Aucun retard toléré sur les extensions de sécurité.
4. Extensions inactives : désinstallez, ne vous contentez pas de désactiver. Le code d’une extension désactivée reste exécutable.
5. Extensions abandonnées : passez chaque plugin au vérificateur, une extension retirée du répertoire ne se signale pas toute seule.
6. Énumération REST : ouvrez /wp-json/wp/v2/users sur votre domaine. Si vos identifiants s’affichent, bloquez l’énumération.
7. Fichiers exposés : cherchez phpinfo.php, des .sql, .zip, .bak à la racine, un /.git accessible. Supprimez ou bloquez.
8. wp-config.php : DISALLOW_FILE_EDIT à true, permissions en 600, salts régénérés au moindre doute.
9. En-têtes HTTP : vérifiez la présence de X-Content-Type-Options, X-Frame-Options, Referrer-Policy et HSTS.
10. Sauvegardes : une restauration testée récemment, stockée hors du serveur. Une sauvegarde jamais restaurée est une hypothèse, pas une sauvegarde.

Cette checklist éteint l’incendie. Pour le durcissement complet qui vient après (pare-feu, double authentification, HTTPS forcé, protection de la base de données), enchaînez avec mon guide pour sécuriser WordPress étape par étape. L’audit diagnostique et priorise. Le durcissement, lui, répare pour de bon.

Faut-il auditer soi-même ou déléguer à un expert ?

Question de temps, d’enjeu et d’accès technique. La checklist ci-dessus est à votre portée dès aujourd’hui, gratuitement. L’analyse des logs serveur, la vérification d’intégrité du core ou le tri d’une base à 4 000 comptes demandent en revanche un accès SSH et l’habitude d’interpréter ce qui en sort. Voici comment je situe les trois niveaux.

Niveau	Ce que ça couvre	Temps	Coût
Checklist express (ci-dessus)	Les 10 vérifications urgentes, en autonomie	30 min	0 €
Audit express en 13 points	Diagnostic global guidé : sécurité, vitesse, SEO	15 min	0 €
Audit de sécurité par un expert	Les 5 axes en profondeur, serveur et logs compris, rapport priorisé	Vous : 0 h	Dès 190 € HT/h

Revenons à ma boutique WooCommerce, promesse tenue. Un mois d’intervention, 16 points corrigés : les salts régénérés, les 3 administrateurs fantômes supprimés, les identifiants d’API sortis du code, les 138 110 sessions zombies purgées, le pare-feu remis d’aplomb, les en-têtes de sécurité posés. Risque global : de HAUT à BAS.

Le piratage avait coûté des jours de panique et un chiffre d’affaires en suspens. L’audit et les correctifs, eux, ont coûté quelques heures facturées. Je vous laisse faire la division…

C’est tout le sens de mes audits : un diagnostic outillé qui aboutit à un constat chiffré et un plan d’action priorisé, rendu sous 48 h. Pas un PDF de 40 pages que personne ne lit, une liste de ce qui est ouvert et de l’ordre dans lequel le refermer.

Questions fréquentes sur l’audit de sécurité WordPress

Combien coûte un audit de sécurité WordPress ?

Fait vous-même avec une checklist et les outils gratuits (Site Health, vérificateur de plugins, veille sécurité) : 0 euro et environ 30 minutes. Confié à un expert : à partir de 190 € HT de l’heure, avec un rapport priorisé rendu sous 48 h qui couvre aussi le serveur, les logs et l’intégrité du core, hors de portée d’un simple scan.

Quelle différence entre un audit de sécurité et Site Health ?

Site Health photographie la configuration technique de votre WordPress : versions, HTTPS, modules PHP, mises à jour. Un audit de sécurité va au-delà du déclaratif : il inspecte les comptes, la surface d’attaque, l’intégrité des fichiers et les logs. Site Health n’aurait vu ni les 1 295 comptes spam ni les identifiants d’API en clair de mon cas réel.

À quelle fréquence auditer son site WordPress ?

Un audit complet par an au minimum, plus un passage systématique après tout événement sensible : un piratage (même "réparé"), un changement de prestataire, ou un signal anormal comme un pic d’inscriptions. Entre deux audits, une veille automatique sur les failles de vos extensions couvre l’essentiel du risque courant.

Un scanner de sécurité comme Wordfence suffit-il ?

Non. Un scanner détecte des signatures de code malveillant connues. Il ne voit ni un compte administrateur oublié, ni des identifiants stockés en dur, ni une extension retirée du répertoire officiel, ni un anti-spam désactivé. Ces négligences de configuration représentent l’essentiel de ce que je trouve en audit, et aucune signature ne les repère.

Mon site a été piraté puis restauré : suis-je tranquille ?

Pas forcément. Une restauration remet en ligne les fichiers d’avant le piratage, mais laisse intactes la faille d’origine, les comptes créés par l’attaquant et les sessions actives. C’est exactement le cas que je décris dans cet article : un site "réparé" dont l’attaque de spam tournait encore six semaines après. Un audit post-incident est indispensable pour refermer les portes.

Mon conseil pour ce soir : ouvrez votre liste d’utilisateurs, puis /wp-json/wp/v2/users sur votre domaine. Deux minutes, et vous saurez déjà dans quelle catégorie joue votre site.

Bon audit ! ;-)

Article original sur WPFormation