Que vérifie réellement un audit de sécurité WordPress ?

Un audit de sécurité WordPress ne consiste pas à installer un plugin, lancer un scan puis transmettre une note sur 100. Un outil automatique peut repérer des versions obsolètes, des fichiers modifiés ou certaines configurations visibles, mais il ne comprend ni le fonctionnement métier du site, ni la légitimité des comptes, ni la qualité réelle des sauvegardes, ni les conséquences d’une faiblesse sur les commandes, les formulaires ou les données.

Un audit de sécurité WordPress sérieux commence par définir un périmètre, rassemble plusieurs sources de preuve, distingue les constats des hypothèses et classe les risques selon leur probabilité, leur impact et le contexte de l’entreprise. Il doit également préciser ce qui n’a pas pu être vérifié.

Selon les accès et l’autorisation accordés, l’analyse peut porter uniquement sur l’exposition publique du site, examiner le back-office et la configuration, contrôler les fichiers, la base de données et l’hébergement, ou inclure des tests actifs encadrés. Ces niveaux ne donnent pas la même profondeur de résultat.

Ce guide détaille ce que vérifie réellement un audit de sécurité WordPress, les livrables à attendre, la différence avec une checklist ou un test d’intrusion et la manière d’exploiter les résultats. Pour faire évaluer un site professionnel, consultez également la prestation Audit de sécurité WordPress GardeWP.

Qu’est-ce qu’un audit de sécurité WordPress ?

Un audit est une évaluation structurée du niveau d’exposition et de maîtrise des risques d’un site. Il rapproche des contrôles techniques, des observations fonctionnelles et le contexte d’usage afin de répondre à quatre questions :

• quels éléments composent réellement le site et son environnement ?
• quelles faiblesses ou incohérences sont confirmées ?
• quel serait leur impact concret pour l’activité ?
• dans quel ordre faut-il les corriger ?

L’audit doit être reproductible autant que possible : chaque constat important est associé à une preuve, à un actif concerné, à une date et à une méthode de vérification. Le rapport doit permettre à un prestataire différent de comprendre le problème sans devoir recommencer toute l’analyse.

Audit externe, back-office, technique ou actif : quelles différences ?

Le mot « audit » recouvre plusieurs profondeurs d’analyse. Le rapport doit indiquer clairement les accès utilisés et les limites qui en découlent.

Niveau d’analyse	Ce qui peut être vérifié	Principales limites
Diagnostic externe ou passif	HTTPS, réponses HTTP, en-têtes, technologies visibles, interfaces exposées, fuites d’information, comportement public, certains composants détectables	Ne voit pas les plugins masqués ou inactifs, les comptes, la base de données, les fichiers internes, les sauvegardes ni la configuration réelle
Audit du back-office	Versions, extensions, thèmes, Site Health, utilisateurs, rôles, réglages, mises à jour, intégrations et configuration accessible depuis WordPress	Vision partielle des fichiers, de l’hébergement, des journaux serveur et des autres installations
Audit technique avec accès hébergement	Fichiers, base de données, permissions, tâches planifiées, journaux, PHP, configuration serveur, sauvegardes, sous-domaines et environnement complet	Dépend de la qualité des journaux, de l’historique disponible et du niveau d’accès accordé
Tests actifs encadrés	Réaction des contrôles, authentification, autorisations, sessions, entrées utilisateur, API et parcours sensibles selon un scénario autorisé	Doivent être explicitement autorisés, limités, non destructifs et parfois réalisés sur une copie ou pendant une fenêtre dédiée

Un audit professionnel peut combiner ces niveaux. Il ne devient toutefois pas automatiquement un test d’intrusion complet. Les objectifs, les techniques autorisées, les environnements concernés et les limites opérationnelles doivent être écrits avant le début des contrôles.

Que faut-il cadrer avant de commencer l’audit ?

La première étape consiste à définir ce qui sera audité. Sans cadrage, le rapport risque de conclure sur le seul site principal alors qu’un sous-domaine, une ancienne préproduction ou une seconde installation partage le même hébergement.

Le cadrage doit préciser :

• les domaines, sous-domaines, multisites, espaces clients et environnements de test ;
• les fonctions critiques : formulaires, vente, paiement, réservation, extranet, téléchargement ou données personnelles ;
• les accès remis à l’auditeur et leur durée de validité ;
• les tests actifs autorisés et ceux qui sont exclus ;
• les horaires ou fenêtres pendant lesquels certains contrôles peuvent être exécutés ;
• les contacts à prévenir en cas d’anomalie critique ;
• la sauvegarde de précaution et la procédure de retour arrière ;
• la forme du livrable, le niveau de détail attendu et la personne qui recevra les résultats.

Les tests susceptibles de modifier des données, déclencher des e-mails, créer une commande ou solliciter fortement le serveur ne doivent jamais être improvisés sur un site en production. Une autorisation explicite et un scénario maîtrisé sont nécessaires.

1. Cartographier le site et sa surface d’exposition

Avant de chercher des failles, l’audit doit comprendre l’architecture. La cartographie recense les composants et les points d’entrée qui peuvent être utilisés légitimement ou détournés.

Cette phase peut inclure :

• le domaine principal, les sous-domaines et les redirections ;
• les installations WordPress voisines, les sites de test et les anciennes copies ;
• le CDN, le pare-feu applicatif, le proxy et les services externes ;
• les interfaces d’administration et d’hébergement ;
• les formulaires, API, webhooks, flux, tâches et accès distants ;
• les répertoires publics, fichiers oubliés, archives et sauvegardes exposées ;
• les prestataires et applications qui disposent d’un accès au site.

Le Web Security Testing Guide de l’OWASP organise également les vérifications autour de la collecte d’information, de la configuration, de l’identité, de l’authentification, des autorisations, des sessions et de la logique métier. L’objectif n’est pas d’appliquer mécaniquement tous les tests, mais de construire un périmètre cohérent avec le site.

2. Contrôler WordPress, les extensions et les thèmes

L’inventaire doit aller au-delà de la liste des composants actifs. Il faut identifier les éléments installés, inactifs, obligatoires, personnalisés ou chargés en dehors de l’écran classique des extensions.

Pour chaque composant, l’audit vérifie notamment :

• la version installée et les mises à jour disponibles ;
• l’origine du fichier et la légitimité de la licence ;
• la date de dernière maintenance et la compatibilité avec l’environnement ;
• les vulnérabilités connues applicables à la version réellement installée ;
• l’utilité métier du composant et la possibilité de le supprimer ;
• la présence de composants abandonnés, dupliqués ou non utilisés ;
• les extensions premium ou personnalisées qui ne disposent pas de sommes de contrôle publiques.

L’écran Outils > Santé du site fournit des informations utiles sur WordPress, les thèmes, les extensions, le serveur, la base de données et certaines permissions. Il constitue une source de preuve, mais il ne remplace pas l’analyse du contexte ni les contrôles hors du back-office.

3. Vérifier l’intégrité des fichiers, de la base et des tâches planifiées

Un site peut être à jour tout en contenant des fichiers ajoutés, des modifications non documentées ou des données injectées. L’audit doit donc vérifier l’intégrité sans assimiler toute personnalisation à une infection.

Les contrôles peuvent porter sur :

• les fichiers du cœur WordPress comparés aux fichiers officiels ;
• les extensions et thèmes issus de sources vérifiables ;
• les fichiers récemment créés ou modifiés ;
• les répertoires uploads, mu-plugins, les fichiers de configuration et les règles serveur ;
• les scripts exécutables placés dans des zones qui devraient principalement contenir des médias ;
• les options, widgets, contenus, comptes et scripts stockés dans la base de données ;
• les événements WordPress, tâches serveur et automatisations externes ;
• les différences entre production, préproduction et sauvegardes de référence.

La commande officielle wp core verify-checksums permet de comparer les fichiers du cœur aux sommes de contrôle de WordPress.org. Un résultat correct ne valide toutefois ni wp-content, ni la base de données, ni les composants premium, ni les fichiers supplémentaires : il s’agit d’un contrôle parmi d’autres.

4. Examiner les utilisateurs, les rôles et l’authentification

Une grande partie du risque repose sur les comptes disposant de droits élevés. L’audit ne vérifie pas seulement la robustesse théorique des mots de passe : il cherche à savoir qui peut faire quoi, pourquoi cet accès existe et comment il est protégé.

Les points de contrôle comprennent notamment :

• la liste des administrateurs, super-administrateurs et comptes techniques ;
• les comptes anciens, partagés, génériques ou rattachés à d’anciens prestataires ;
• la cohérence entre les rôles et les besoins réels ;
• les capacités personnalisées ajoutées par des extensions ;
• la double authentification des comptes privilégiés ;
• les mécanismes de réinitialisation, de création et de suppression des comptes ;
• les mots de passe d’application, clés API, comptes SMTP et autres accès révocables ;
• les accès à l’hébergement, au SFTP, au SSH, à la base de données, au registrar et au CDN.

La documentation WordPress sur les utilisateurs, rôles et capacités recommande le principe du moindre privilège : chaque compte ne doit disposer que des droits nécessaires à sa mission. Un audit doit donc signaler les droits excessifs, mais aussi proposer une organisation réaliste qui ne bloque pas l’exploitation du site.

5. Contrôler la configuration WordPress et les fichiers sensibles

Les réglages de production doivent limiter l’exposition d’informations, les possibilités d’exécution et les modifications non maîtrisées. Les contrôles exacts dépendent de l’hébergement et des besoins du site.

L’audit peut notamment examiner :

• la protection et les droits de lecture du fichier wp-config.php ;
• l’affichage des erreurs et le mode de débogage sur le site public ;
• l’éditeur de fichiers de thèmes et d’extensions dans l’administration ;
• les permissions de fichiers et de répertoires ;
• les clés et secrets présents dans les fichiers, variables ou bases de données ;
• les fichiers de journalisation, sauvegardes, exports SQL ou archives accessibles publiquement ;
• le comportement de XML-RPC, de la REST API et des points d’accès réellement utilisés ;
• les règles de réécriture, restrictions d’exécution et protections propres à l’hébergement.

Le guide officiel Hardening WordPress couvre notamment les mises à jour, les mots de passe, les permissions, la base de données, wp-admin, wp-config.php, l’édition de fichiers, les sauvegardes, les journaux et la surveillance. Ces recommandations doivent être adaptées : une règle appliquée sans tenir compte d’un multisite, d’une extension ou d’un hébergement managé peut provoquer une panne.

6. Vérifier l’hébergement, PHP, HTTPS et la couche web

WordPress ne fonctionne pas isolément. Une configuration correcte du CMS ne compense pas un serveur obsolète, une séparation insuffisante entre plusieurs sites ou des accès d’hébergement mal protégés.

L’analyse peut inclure :

• la version de PHP et les composants encore supportés ;
• le certificat, le chiffrement HTTPS et les redirections vers la version sécurisée ;
• les en-têtes HTTP pertinents pour le fonctionnement réel du site ;
• les informations techniques divulguées dans les réponses ou pages d’erreur ;
• la séparation entre sites, comptes système, bases et environnements ;
• les interfaces d’administration du serveur, du CDN, du DNS et du registrar ;
• le pare-feu applicatif, les limitations de requêtes et les protections de connexion ;
• les sous-domaines oubliés, services de test, espaces de stockage et anciennes configurations.

Les contrôles de configuration et de déploiement font partie des grandes familles du guide OWASP. Ils concernent notamment la plateforme applicative, les fichiers oubliés, les interfaces d’administration, les permissions, HTTPS et les en-têtes. Le rapport doit toutefois distinguer une bonne pratique générale d’un risque exploitable dans le contexte précis du site.

7. Examiner les formulaires, API et fonctions métier

Un site professionnel ne se résume pas à son administration. Les fonctions qui créent, modifient ou transmettent des données doivent être contrôlées selon leur criticité.

Selon le site, l’audit peut porter sur :

• les formulaires publics, leurs validations, protections anti-abus et destinataires ;
• les téléversements de fichiers et les formats autorisés ;
• les actions accessibles à un visiteur, un client, un membre ou un administrateur ;
• les API REST, webhooks, clés d’intégration et automatisations ;
• les parcours de création de compte, connexion, réinitialisation et changement d’adresse ;
• les commandes, coupons, paiements, remboursements et exports WooCommerce ;
• les espaces privés, documents, téléchargements et données réservées ;
• les e-mails transactionnels et les services tiers qui reçoivent des données.

Cette partie nécessite souvent des tests fonctionnels. Elle doit vérifier qu’un utilisateur ne peut pas accéder à une fonction ou à une donnée au-delà de son rôle, sans détailler dans le rapport public des procédures qui faciliteraient un détournement.

8. Auditer les sauvegardes et la capacité de restauration

La présence d’un plugin de sauvegarde ou d’une option chez l’hébergeur ne prouve pas que le site peut être restauré. L’audit doit évaluer la chaîne complète : création, stockage, rétention, protection, restauration et contrôle.

Les vérifications portent notamment sur :

• la sauvegarde des fichiers, médias, extensions, thèmes, configurations et base de données ;
• la fréquence adaptée au rythme de modification du site ;
• la conservation de plusieurs versions ;
• le stockage séparé de l’hébergement principal ;
• la protection des archives et des identifiants de stockage ;
• les alertes en cas d’échec ;
• la dernière restauration testée et les résultats du test ;
• le temps et la perte de données acceptables pour l’activité.

La documentation WordPress distingue la sauvegarde des fichiers de la sauvegarde de la base de données. Un jeu de restauration complet doit réunir les deux de façon cohérente. Pour approfondir cette partie, consultez également le guide Sauvegarde WordPress : fréquence et bonnes pratiques.

9. Évaluer les journaux, la surveillance et les alertes

La sécurité ne dépend pas uniquement de la prévention. Il faut pouvoir détecter une anomalie, dater son apparition, mesurer son périmètre et conserver suffisamment d’informations pour comprendre l’incident.

L’audit vérifie par exemple :

• les journaux d’accès, d’erreurs, PHP, serveur, CDN et sécurité disponibles ;
• la durée de conservation et l’horodatage ;
• les événements WordPress enregistrés : connexions, changements de rôles, installations ou réglages sensibles ;
• les alertes de disponibilité, d’échec de sauvegarde, de modification ou de vulnérabilité ;
• les destinataires, canaux et procédures d’escalade ;
• la capacité à distinguer une alerte utile d’un bruit permanent ignoré par l’équipe.

Une surveillance efficace associe des contrôles internes et externes. La documentation WordPress recommande notamment le suivi de disponibilité et de performance, mais une stratégie de sécurité doit également prévoir les événements liés aux accès, aux fichiers, aux mises à jour et aux sauvegardes.

Quelle différence entre un scanner, une checklist, un audit et un test d’intrusion ?

Approche	Utilité principale	Ce qu’elle ne remplace pas
Scanner automatisé	Repérer rapidement des signaux techniques répétables et des versions connues	L’analyse des droits, de la logique métier, des faux positifs, des sauvegardes et du contexte
Checklist	Vérifier que les bonnes pratiques de base ont été envisagées	La preuve de leur application, leur pertinence pour le site et la recherche de problèmes non prévus
Audit de sécurité	Croiser plusieurs contrôles, preuves et enjeux afin de produire un diagnostic priorisé	La correction elle-même et, sauf mention explicite, un test d’intrusion exhaustif
Test d’intrusion	Évaluer par des tests actifs autorisés si certaines faiblesses peuvent être exploitées	L’inventaire complet de maintenance, la gouvernance des accès, les sauvegardes et le suivi dans le temps

Ces approches sont complémentaires. Une checklist peut préparer l’audit, un scanner peut fournir des indices, l’audit peut recommander des tests actifs ciblés, puis une contre-vérification peut confirmer que les corrections ont été appliquées.

Comment les risques doivent-ils être priorisés ?

La gravité ne dépend pas uniquement d’une classification technique. Le rapport doit tenir compte de l’exposition, des droits nécessaires, de la facilité d’abus, des données concernées, des protections déjà présentes et de l’impact métier.

Priorité	Exemples de situation	Traitement attendu
Critique	Accès non autorisé confirmé, exécution ou modification possible, données ou paiements exposés, site déjà compromis	Confinement ou correction immédiate, décision d’incident et vérification étendue
Élevée	Composant vulnérable exposé, administrateur insuffisamment protégé, sauvegardes inutilisables sur un site critique	Correction prioritaire planifiée à très court terme et contrôle après intervention
Moyenne	Configuration affaiblie nécessitant plusieurs conditions, droits excessifs sans abus observé, journalisation insuffisante	Remédiation planifiée, réduction de l’exposition et amélioration des contrôles
Faible ou amélioration	Bonne pratique manquante avec impact limité, information technique peu sensible, documentation incomplète	Correction lors d’un cycle de maintenance, sauf contexte particulier

Une conclusion doit expliquer pourquoi le risque est classé à ce niveau. Un simple libellé « critique » sans scénario, preuve ni actif concerné est difficilement exploitable.

Quels livrables attendre d’un audit de sécurité WordPress ?

Le livrable doit pouvoir être lu à deux niveaux : une synthèse décisionnelle pour le responsable du site et une partie technique permettant d’organiser les corrections.

Un rapport utile contient généralement :

• le périmètre, la date, les accès et les méthodes utilisées ;
• les exclusions, contraintes et limites de l’analyse ;
• une synthèse du niveau de risque et des décisions urgentes ;
• l’inventaire des actifs et composants principaux ;
• chaque constat avec preuve, actif touché, impact et scénario de risque ;
• une recommandation adaptée à l’environnement, pas seulement une règle générique ;
• un classement par priorité, effort et dépendances ;
• les actions rapides, les chantiers structurels et les contrôles récurrents ;
• les points qui nécessitent un diagnostic complémentaire ou un test actif ;
• les modalités de contre-vérification après correction.

Le rapport ne doit pas exposer inutilement des secrets, mots de passe, clés complètes ou détails sensibles. Les preuves peuvent être masquées, et les accès doivent être transmis par un canal distinct puis révoqués après la mission.

Ce qu’un audit ne peut pas garantir

Même approfondi, un audit reste une photographie réalisée à une date donnée. Il ne peut pas garantir qu’aucune vulnérabilité n’existe ou qu’un incident ne surviendra jamais.

Il ne prouve pas non plus automatiquement :

• l’absence historique de compromission si les journaux nécessaires n’existent plus ;
• la propreté de toutes les sauvegardes non analysées ;
• la sécurité du poste informatique d’un administrateur ;
• la résistance à tous les scénarios d’attaque possibles ;
• l’efficacité future des mesures si les mises à jour et la surveillance s’arrêtent ;
• la correction des constats tant qu’une remédiation puis une contre-vérification n’ont pas été réalisées.

Une formulation honnête distingue « aucun indicateur trouvé dans le périmètre examiné » de « le site n’a jamais été compromis ». La première peut être étayée ; la seconde exige souvent des preuves historiques qui n’existent pas.

Que faire après l’audit ?

L’audit n’apporte de valeur que si ses conclusions sont transformées en actions suivies. Le plan de remédiation peut être organisé en quatre étapes :

1. traiter l’urgence : compromission, vulnérabilité exposée, accès inconnu ou sauvegarde critique défaillante ;
2. réduire la surface d’attaque : supprimer les composants inutiles, fermer les accès et corriger les droits ;
3. durcir et documenter : configuration, authentification, sauvegardes, procédures et responsabilités ;
4. contrôler dans le temps : contre-vérification, mises à jour, surveillance et nouvel audit après un changement important.

La correction peut relever d’une prestation de sécurisation WordPress, d’un nettoyage malware si une compromission est détectée, ou d’une maintenance de sécurité pour les contrôles récurrents.

Quelles informations préparer avant de demander un audit ?

Pour obtenir un périmètre et un devis cohérents, préparez :

• l’URL du site et la liste des sous-domaines ou environnements associés ;
• le type de site et ses fonctions critiques ;
• l’hébergeur et les éventuels services CDN, WAF ou proxy ;
• le nombre approximatif d’utilisateurs et de comptes administrateurs ;
• les incidents, alertes ou changements récents ;
• la présence de WooCommerce, d’un espace membre, de paiements ou de données sensibles ;
• les sauvegardes disponibles et la date du dernier test de restauration ;
• les contraintes de production et les tests qui ne doivent pas être réalisés.

Ne transmettez pas de mot de passe dans le formulaire initial. Les accès nécessaires doivent être créés ou communiqués après cadrage, par un canal sécurisé, avec le niveau de droit minimal et une durée limitée.

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

Peut-on auditer un site WordPress sans accès ?

Oui, mais l’analyse reste externe. Elle peut évaluer l’exposition publique, HTTPS, certaines interfaces, les réponses HTTP et des informations visibles. Elle ne peut pas confirmer la liste complète des composants, les comptes, les fichiers internes, la base de données, les tâches ou les sauvegardes.

Un audit installe-t-il forcément un plugin de sécurité ?

Non. Des outils temporaires peuvent être utilisés si le périmètre le justifie, mais l’audit doit pouvoir combiner des observations externes, les fonctions natives de WordPress, les fichiers, les journaux et l’hébergement. Toute installation doit être autorisée, documentée puis retirée ou conservée volontairement.

L’audit risque-t-il de casser le site ?

Les contrôles passifs et en lecture seule présentent peu de risque. Les tests actifs peuvent provoquer des effets de bord s’ils sont mal cadrés. C’est pourquoi les actions autorisées, la sauvegarde, l’environnement, la fenêtre de test et les scénarios d’arrêt doivent être définis avant leur exécution.

Un audit détecte-t-il tous les malwares ?

Non. Il peut rechercher des indicateurs, des incohérences et des mécanismes suspects, mais l’absence de détection ne prouve pas l’absence absolue de compromission. Une suspicion d’incident peut nécessiter une analyse dédiée des fichiers, de la base, des journaux et de la chronologie.

Quelle est la différence entre audit et nettoyage malware ?

L’audit évalue et priorise les risques. Le nettoyage intervient lorsqu’une compromission doit être supprimée, que les accès doivent être révoqués et que le point d’entrée doit être corrigé. Un audit peut révéler la nécessité d’un nettoyage, mais il ne faut pas confondre le rapport avec l’intervention corrective.

L’audit comprend-il les corrections ?

Pas nécessairement. Le périmètre doit préciser si la mission comprend uniquement l’analyse et le rapport, quelques corrections urgentes, une remédiation complète ou une contre-vérification. Séparer l’audit de la correction permet aussi de conserver une trace claire de l’état initial.

À quelle fréquence faut-il auditer un site WordPress ?

La fréquence dépend de la criticité, du rythme de changement et des contrôles de maintenance. Un nouvel audit est pertinent après une refonte, une migration, un changement d’agence, l’ajout d’une fonction sensible, un incident, ou lorsque le site n’a jamais fait l’objet d’un état des lieux documenté.

Comment savoir si le rapport est exploitable ?

Vérifiez qu’il indique le périmètre, les limites, les preuves, les actifs touchés, l’impact, la priorité, les recommandations et les modalités de contrôle après correction. Une liste générique de bonnes pratiques sans preuve ni ordre de traitement n’est pas suffisante pour piloter une remédiation.