Audit de sécurité WordPress : le déroulé complet en huit points
Un audit de sécurité WordPress consiste à examiner méthodiquement un site, point par point, pour repérer les failles avant qu’un pirate ne le fasse. Ce n’est pas un simple scan automatique qui liste des alertes génériques. C’est donc un travail manuel qui croise plusieurs sources : fichiers, base de données, configuration serveur et comportements du site en production.
Je fais régulièrement ce type d’audit sur des sites WordPress, souvent après une alerte, parfois en prévention avant une refonte ou une mise en conformité. Dans les deux cas, la méthode reste la même : huit étapes, dans un ordre précis, pour ne rien laisser de côté.
Dans cet article, je détaille le déroulé complet d’un audit de sécurité WordPress, ce que je trouve le plus souvent sur le terrain, et ce que contient le livrable remis au client à la fin.
Pourquoi un audit de sécurité WordPress va plus loin qu’un scan
Un scan automatique compare les fichiers et versions installées à une base de vulnérabilités connues. C’est utile, mais limité. En effet, il ne comprend pas le contexte du site ni ses usages réels.
Les limites d’un scanner automatique
Un scanner ne détecte pas une mauvaise configuration des rôles utilisateurs. Il ne voit pas non plus un mot de passe faible réutilisé sur plusieurs comptes. Par exemple, il signale des CVE connues, c’est-à-dire des failles déjà répertoriées publiquement, mais passe à côté des erreurs de logique métier.
Ce qu’apporte l’analyse humaine
En pratique, je croise les résultats du scan avec une lecture manuelle du code, des logs serveur et de la configuration. Par exemple, un plugin à jour peut quand même être mal configuré et exposer des données. Seul un œil humain repère ce type de problème.
Un audit, pas un diagnostic de lenteur
L’audit de sécurité ne doit pas être confondu avec un diagnostic de performance. Si votre site est lent, la méthode est différente et je l’explique dans mon article sur le diagnostic complet d’un site WordPress lent.
Les huit points d’un audit de sécurité WordPress
Voici l’ordre que je suis systématiquement, du plus général au plus spécifique.
- Inventaire du cœur, des thèmes et des plugins : versions installées, comparaison avec les versions maintenues officiellement.
- Analyse des comptes utilisateurs : rôles, permissions, comptes inactifs ou oubliés.
- Vérification des fichiers : recherche de fichiers modifiés, ajoutés ou suspects dans l’arborescence.
- Contrôle de la base de données : recherche de contenus injectés, de comptes administrateurs cachés.
- Audit de la configuration serveur : permissions des fichiers, exposition de wp-config.php, en-têtes HTTP.
- Analyse des journaux (logs) : tentatives de connexion, requêtes suspectes, schémas d’attaque.
- Test des formulaires et points d’entrée : formulaire de contact, zone de connexion, API REST.
- Vérification des sauvegardes et du plan de reprise : existence, fréquence, test de restauration.
Du plus visible au plus technique
Les premiers points sont rapides à vérifier. Les derniers demandent plus de temps, car ils touchent à la configuration serveur et aux logs. C’est pourquoi je garde cet ordre : il permet d’éliminer vite les problèmes évidents avant de creuser.
Une checklist, pas une liste figée
Chaque site a ses particularités. Par exemple, un site e-commerce demande une attention particulière sur les formulaires de paiement. En revanche, un site vitrine avec formulaire de contact nécessite surtout de vérifier les protections anti-spam et les permissions.
Ce que je trouve le plus souvent lors d’un audit de sécurité
Après plusieurs années à faire ce travail, certains problèmes reviennent sans cesse.
Des extensions obsolètes ou abandonnées
C’est le cas le plus fréquent. Un plugin installé il y a longtemps, jamais mis à jour, parfois abandonné par son auteur. Ce plugin devient alors une porte d’entrée pour les attaquants, même si le reste du site est bien tenu.
Des comptes administrateurs superflus
Je trouve souvent plusieurs comptes avec le rôle administrateur, alors qu’un seul ou deux suffiraient. Un ancien prestataire, un stagiaire, un compte de test : autant d’accès qui restent actifs sans raison.
Une absence de séparation des rôles
Donner le rôle administrateur à toute personne qui publie du contenu est une erreur classique. En effet, un rédacteur n’a pas besoin d’accéder aux réglages du site. Je détaille cette logique de permissions dans mon article sur le durcissement avancé des rôles utilisateurs et de l’API REST. La documentation officielle des rôles et permissions WordPress, disponible sur developer.wordpress.org, détaille d’ailleurs précisément les capacités attachées à chaque rôle.
Des traces d’intrusion passées inaperçues
Sur certains sites, je trouve des fichiers injectés datant de plusieurs mois. Le site fonctionne normalement en apparence, mais il héberge en réalité du code malveillant en arrière-plan, parfois utilisé pour envoyer du spam ou rediriger des visiteurs.
Le livrable remis au client après l’audit de sécurité WordPress
Un audit sans rapport exploitable ne sert à rien. Le livrable doit donc être clair, priorisé et actionnable.
La structure du rapport
Je remets toujours un document organisé en trois parties : le constat général, le détail des failles trouvées, puis un plan d’action classé par priorité. Chaque faille est expliquée en langage simple, sans jargon inutile.
La priorisation des correctifs
Toutes les failles ne se valent pas. Ainsi, je classe chaque point selon son niveau de risque réel et sa facilité de correction. Par conséquent, une faille critique facile à corriger passe toujours avant une faille mineure complexe à traiter.
| Niveau de risque | Exemple | Délai conseillé |
|---|---|---|
| Critique | Fichier malveillant actif, compte admin inconnu | Immédiat |
| Élevé | Plugin obsolète avec faille connue | Sous 48 heures |
| Moyen | Permissions de fichiers trop larges | Sous 2 semaines |
| Faible | En-têtes HTTP de sécurité absents | Sous 1 mois |
Un rapport compréhensible sans jargon technique
Le client n’est pas toujours technicien. Le rapport doit donc rester lisible par un dirigeant pressé. Les détails techniques existent, mais en annexe, pour les équipes qui en ont besoin.
Audit de sécurité WordPress : différence avec un simple scan automatique
C’est la question qu’on me pose le plus souvent. Un scan donne une liste. Un audit, en revanche, donne une analyse.
Le scan : un point de départ, pas une conclusion
Un scan automatique reste utile en continu, pour une surveillance régulière. Il complète d’ailleurs bien le monitoring que je décris dans mon article sur le monitoring WordPress et les outils à utiliser. Mais seul, il ne suffit pas à sécuriser un site.
L’audit : une investigation contextuelle
Un audit prend en compte l’historique du site, ses usages métier et son infrastructure serveur. Par exemple, deux sites avec les mêmes plugins installés peuvent avoir des niveaux de risque totalement différents selon leur configuration serveur.
Quand choisir l’un ou l’autre
Un scan régulier convient en routine de maintenance. Un audit complet s’impose, en revanche, après un piratage, avant une mise en conformité, ou lors d’une refonte importante. Si votre site a déjà été compromis, la démarche est différente et je la détaille dans mon article sur la récupération d’un site WordPress piraté.
Comment se déroule concrètement une intervention
Voici les étapes concrètes d’une intervention type, de la prise de contact jusqu’à la livraison.
La phase de préparation
Avant toute analyse, je demande un accès complet : hébergement, administration WordPress, et si possible un accès FTP ou SSH. Une sauvegarde complète est systématiquement réalisée avant toute manipulation, pour pouvoir revenir en arrière en cas de besoin.
# Exemple de sauvegarde avant intervention
wp db export backup-avant-audit.sql
tar -czvf backup-fichiers.tar.gz /chemin/vers/wordpress
La phase d’analyse
Je parcours ensuite les huit points listés plus haut, dans l’ordre. Chaque anomalie est documentée avec une capture ou un extrait de code, pour appuyer le rapport final.
La restitution et le suivi
Je présente ensuite le rapport au client et réponds aux questions, puis je propose un accompagnement pour la correction si besoin. Un audit isolé a peu de valeur sans suivi dans le temps, c’est pourquoi je recommande souvent un plan de maintenance derrière, comme celui décrit dans mon article sur le plan de maintenance WordPress pour anticiper les incidents.
Questions fréquentes
Combien de temps dure un audit de sécurité WordPress ?
La durée varie selon la taille du site et le nombre de plugins installés. Un site simple se traite en quelques heures. En revanche, un site complexe avec e-commerce demande davantage de temps, car les points d’entrée sont plus nombreux.
Un audit de sécurité WordPress garantit-il l’absence totale de faille ?
Non. Un audit réduit fortement les risques en corrigeant les failles connues au moment de l’analyse. Aucune garantie absolue n’existe, car de nouvelles vulnérabilités apparaissent régulièrement sur le cœur, les thèmes et les plugins.
Faut-il refaire un audit de sécurité WordPress régulièrement ?
Oui, en complément d’un monitoring continu. Un audit complet une à deux fois par an reste raisonnable, avec une surveillance automatisée entre les deux pour détecter rapidement toute anomalie nouvelle.
Quelle différence entre un audit de sécurité et un audit de performance ?
L’audit de sécurité cherche des failles et des vulnérabilités. L’audit de performance, lui, cherche des causes de lenteur, comme un hébergement sous-dimensionné ou un cache mal configuré. Les deux démarches restent donc complémentaires mais distinctes.
Conclusion
Un audit de sécurité WordPress structuré, en huit points, permet de couvrir le site dans sa globalité : fichiers, comptes, base de données, serveur et logs. C’est cette méthode, et non un simple scan, qui donne une vision fiable des risques réels.
Si vous préférez déléguer cette vérification, je reste disponible pour réaliser l’audit de sécurité WordPress de votre site.
