Un site WordPress peut fonctionner normalement tout en présentant des faiblesses : extensions obsolètes, comptes inutilisés, sauvegardes non testées ou réglages exposés. Un audit de sécurité WordPress ne consiste pas à installer un plugin et à regarder un score. Il sert à comprendre ce qui est réellement exposé, ce qui doit être corrigé en priorité et ce qui doit être surveillé dans le temps.
Pour une PME, l’objectif est simple : éviter qu’une mise à jour, un accès compromis ou une faille connue transforme un incident limité en interruption du site.
Pourquoi réaliser un audit de sécurité WordPress ?
Les attaques automatisées ciblent les sites WordPress en continu. Elles recherchent notamment des versions vulnérables, des extensions abandonnées, des comptes trop permissifs et des fichiers accessibles publiquement. Un audit permet de distinguer le risque réel des alertes sans conséquence immédiate.
Il est particulièrement utile avant de reprendre un site confié à un nouveau webmaster, après un piratage, avant une refonte ou lorsque personne ne sait précisément quelles extensions, quels comptes et quelles sauvegardes sont encore actifs.
Vérifier les versions et les extensions
Le premier contrôle porte sur le cœur de WordPress, le thème et les extensions. Il faut identifier les versions installées, les mises à jour disponibles, les extensions abandonnées et celles qui ne sont plus nécessaires.
- WordPress et version de PHP ;
- thème actif et thème enfant ;
- extensions actives et inactives ;
- extensions premium et état de leurs licences ;
- composants abandonnés ou remplacés par une solution plus fiable.
Une extension inactive mais conservée sur le serveur n’apporte généralement rien et peut augmenter la surface d’exposition. Elle doit être supprimée seulement après vérification de son rôle et d’une sauvegarde récupérable.
Contrôler les comptes et les accès
Un audit sérieux ne s’arrête pas au mot de passe administrateur. Il faut recenser les utilisateurs, leurs rôles, les comptes d’anciens prestataires et les accès liés à l’hébergement, au nom de domaine, à la messagerie et aux outils de mesure.
Les comptes qui ne servent plus doivent être supprimés ou désactivés après vérification de leur propriété. Les comptes partagés sont à éviter : des comptes nominatifs facilitent la traçabilité et permettent de retirer un accès sans bloquer toute l’équipe.
Vérifier les sauvegardes et la restauration
Une sauvegarde n’est utile que si elle peut être restaurée. Il faut donc vérifier sa fréquence, son emplacement, sa rétention et surtout l’existence d’un test de restauration récent.
- base de données incluse ;
- fichiers, médias, thèmes et extensions inclus ;
- copie indépendante du serveur principal ;
- historique de plusieurs versions ;
- procédure claire de restauration.
Un export XML WordPress n’est pas une copie complète du site. Il ne remplace ni la base de données ni les fichiers nécessaires au fonctionnement de l’installation.
Examiner la configuration visible
Certains réglages peuvent révéler des informations techniques ou exposer des fichiers inutiles. Selon le contexte, on vérifie notamment HTTPS, les redirections, les en-têtes de sécurité, les fichiers de debug, les sauvegardes accessibles et les endpoints WordPress exposés.
Ces contrôles doivent rester proportionnés. Un audit externe ne remplace pas un test d’intrusion avec autorisation, et il ne faut pas modifier un réglage sensible sans sauvegarde ni plan de retour.
Contrôler le serveur et l’environnement
La sécurité du site dépend aussi de l’hébergement : version PHP, certificats, droits de fichiers, accès SFTP ou SSH, sauvegardes serveur, journalisation et capacité à isoler une préproduction.
Un site correctement configuré mais hébergé sur un compte partagé dont les accès sont inconnus reste difficile à maintenir. L’audit doit donc préciser ce qui relève de WordPress et ce qui relève de l’hébergement.
Vérifier les formulaires et les emails
Un formulaire qui fonctionne visuellement peut ne pas délivrer ses messages. Il faut vérifier le traitement des données, l’envoi SMTP, les adresses destinataires et la protection contre le spam.
Cette étape est importante pour une PME : un site disponible mais incapable de recevoir une demande de contact représente un risque commercial, même si aucune alerte de sécurité n’est affichée.
Une grille de contrôle simple
Pour éviter un rapport difficile à exploiter, chaque point doit déboucher sur une décision concrète :
| Contrôle | Risque à rechercher | Preuve utile | Action possible |
|---|---|---|---|
| Extensions | Version obsolète ou abandonnée | Inventaire et version | Mettre à jour, remplacer ou supprimer après sauvegarde |
| Utilisateurs | Compte ancien ou rôle trop élevé | Liste des comptes et rôles | Désactiver, supprimer ou réduire les droits |
| Sauvegardes | Copie inutilisable ou stockée au même endroit | Date et test de restauration | Créer une copie indépendante et tester la restauration |
| Configuration | Fichier, endpoint ou version exposée | Contrôle externe et réglages | Corriger avec sauvegarde et possibilité de retour |
| Formulaires | Message perdu ou spam non filtré | Test d’envoi et réception | Corriger SMTP, destinataire et protection anti-spam |
Comment prioriser les corrections ?
Je recommande de classer les constats en trois niveaux :
- Urgent : compte compromis, malware, version vulnérable exploitée, sauvegarde absente ou site inaccessible ;
- Important : extension obsolète, accès d’ancien prestataire, absence de test de restauration ou configuration exposée ;
- À planifier : amélioration des droits, documentation, préproduction et procédure de maintenance.
Le but n’est pas d’obtenir un score parfait. Le but est de savoir quelles actions réduisent réellement le risque et dans quel ordre les réaliser.
Que doit contenir le compte rendu d’audit ?
Un compte rendu utile d’audit de sécurité WordPress doit indiquer le périmètre vérifié, les éléments non vérifiables, les risques observés, les preuves disponibles et les actions recommandées. Il doit aussi préciser ce qui n’a pas été testé : paiement, restauration complète, intrusion ou fonctionnement d’une intégration tierce.
Cette précision évite de présenter un simple scan externe comme un audit de sécurité complet.
À quoi ressemble un compte rendu utile ?
Un exemple de conclusion peut être formulé ainsi : « Le site fonctionne, mais trois risques doivent être traités avant la prochaine mise à jour : deux extensions obsolètes, un compte administrateur non identifié et une sauvegarde dont la restauration n’a jamais été testée. Les autres points sont à planifier dans la maintenance mensuelle. »
Ce format permet au dirigeant de comprendre la priorité, le risque et la prochaine action sans confondre un contrôle de sécurité avec un test d’intrusion.
Après l’audit : corriger ou mettre en place une maintenance
Un audit de sécurité WordPress est une étape de décision. Les corrections peuvent être réalisées ponctuellement ou intégrées à une maintenance WordPress régulière : mises à jour contrôlées, sauvegardes vérifiées, surveillance des erreurs et suivi des accès.
Si ton site WordPress présente déjà une panne ou une erreur visible, il faut d’abord traiter le dépannage WordPress. Si le site fonctionne mais que son état est inconnu, l’audit permet de préparer une maintenance adaptée.
Découvrir la maintenance WordPress, consulter le dépannage WordPress ou décrire la situation de ton site.
Ressources utiles
- Documentation WordPress sur les sauvegardes
- Guide officiel WordPress pour renforcer la sécurité
- Bonnes pratiques de sécurisation de WordPress
FAQ
Un audit de sécurité WordPress garantit-il qu’un site ne sera jamais piraté ?
Non. Il réduit les risques identifiés et améliore la capacité à réagir, mais aucune analyse ne garantit l’absence future d’incident.
Faut-il installer un plugin de sécurité pour faire un audit ?
Pas nécessairement. Un contrôle peut commencer par l’inventaire, les accès, les versions, les sauvegardes et la configuration. Un plugin peut compléter la surveillance, mais il ne remplace pas l’analyse du contexte.
Un audit est-il utile après un piratage déjà nettoyé ?
Oui. Restaurer une sauvegarde ou supprimer un fichier infecté ne suffit pas toujours à expliquer l’origine de l’incident. Il faut vérifier les accès, les versions et les traces disponibles avant de considérer le site comme stabilisé.
