audit sécurité wordpress
Cartographier les accès et réduire la surface d’attaque (à vérifier en premier)
audit sécurité wordpress — Quand un site WordPress se fait compromettre, la porte d’entrée est très souvent… un accès. Avant même d’inspecter le code ou les extensions, un audit efficace commence par la cartographie des comptes, des rôles et des points d’authentification. L’objectif est simple : réduire drastiquement le nombre de chemins exploitables et rendre chaque tentative d’intrusion coûteuse.
Commencez par inventorier tous les utilisateurs WordPress (y compris ceux qui ne se connectent plus). Repérez les comptes admin génériques, les e-mails obsolètes, les comptes partagés entre plusieurs personnes, et surtout les comptes dont le rôle est plus élevé que nécessaire. Le principe du moindre privilège s’applique : un rédacteur n’a pas besoin d’être administrateur, un prestataire ponctuel ne doit pas garder des droits élevés une fois sa mission terminée.
Vérifiez ensuite la sécurité de la page de connexion : politique de mots de passe (longueur, complexité, unicité), activation d’une double authentification (2FA), limitations de tentatives (anti-brute force), et présence d’un mécanisme anti-énumération des utilisateurs. Une énumération permet de découvrir des logins valides, puis de lancer des attaques par force brute ciblées.
Enfin, contrôlez les accès hors WordPress qui contournent parfois les protections : FTP/SFTP, SSH, panel d’hébergement, phpMyAdmin, webmail. Un compte hébergeur compromis équivaut souvent à une compromission totale du site. Dans votre audit, exigez des accès individuels (pas de compte partagé), des mots de passe uniques et idéalement une authentification forte côté hébergeur.
Mises à jour, dépendances et composants : le cœur de la prévention
Un audit pertinent vérifie non seulement si tout est à jour, mais aussi ce qui doit être mis à jour, ce qui ne devrait plus être présent et ce qui est maintenu. Dans WordPress, la majorité des compromissions exploite des failles connues dans des plugins et thèmes, parfois corrigées depuis des mois.
Contrôlez la version de WordPress (cœur), du thème actif et de tous les plugins. Relevez aussi les éléments désactivés : un plugin désactivé mais toujours installé peut rester exploitable selon la faille, ou être réactivé par un attaquant qui a déjà obtenu un accès admin. La règle la plus sûre : supprimer ce qui ne sert pas.
La partie la plus délicate est la suppression sans casse fonctionnelle. Avant de retirer un composant, identifiez son rôle exact (shortcodes, widgets, blocs, scripts, intégrations). Préparez un plan de retour arrière. Pour une méthode propre et progressive, vous pouvez vous appuyer sur ce guide interne : Comment Supprimer les Plugins Obsolètes Sans Risque.
Dans l’audit, ajoutez un critère souvent oublié : la santé du plugin/thème. Date de dernière mise à jour, compatibilité annoncée, fréquence de correctifs, réputation, existence d’un support actif. Un plugin abandonné est une dette de sécurité.
Vérifier l’intégrité des fichiers et détecter les modifications suspectes
Un site peut être à jour et pourtant infecté. L’audit doit donc inclure une vérification d’intégrité : présence de fichiers inconnus, modifications dans des fichiers sensibles, backdoors, webshells, injections dans le thème ou dans des mu-plugins.
Découvrez nos offres pour la maintenance de sites WordPress
Points à contrôler absolument :
– Le dossier wp-content/uploads : il ne devrait pas contenir de fichiers PHP exécutables. La présence de scripts là-dedans est un signal fort (souvent lié à une porte dérobée).
– Les fichiers wp-config.php et .htaccess : recherche de redirections inconnues, règles d’exécution anormales, ou ajouts de code obscur.
– Les répertoires wp-includes et wp-admin : ils ne doivent pas contenir de fichiers inattendus. Toute anomalie mérite enquête.
– Les fichiers du thème : injections dans functions.php, header.php, footer.php, ou des fichiers au nom légitime mais au contenu obfusqué.
Contrôlez également les tâches planifiées (WP-Cron) : des malwares s’y accrochent pour se réinstaller ou relancer des actions. Un audit sérieux examine les événements cron, les actions récurrentes inconnues et les appels externes suspects.
Durcissement serveur : permissions, PHP, en-têtes et isolation
La sécurité WordPress ne se limite pas au tableau de bord. Un audit doit impérativement évaluer l’environnement d’hébergement, car une configuration trop permissive transforme une petite faille en compromission totale.
Droits de fichiers et d’écriture
Vérifiez les permissions : pas de répertoires en 777, pas de fichiers critiques accessibles en écriture par tout le monde. Les droits exacts varient selon la configuration, mais l’idée reste la même : limiter l’écriture aux répertoires nécessaires (uploads, cache, éventuellement logs) et verrouiller le reste.
Version de PHP et modules
Contrôlez la version de PHP, les modules chargés, et la configuration. Une version obsolète augmente le risque, tout comme des fonctions dangereuses activées sans nécessité. Vérifiez aussi la gestion des erreurs (display_errors) : afficher des erreurs en production peut révéler des chemins, des requêtes SQL, voire des secrets.
En-têtes de sécurité et HTTPS
Assurez-vous que le site force HTTPS, que les cookies sont sécurisés, et que des en-têtes comme HSTS, X-Content-Type-Options, X-Frame-Options (ou CSP), Referrer-Policy sont correctement configurés selon le contexte. L’objectif : réduire les vecteurs XSS, clickjacking et fuites d’informations. Un audit pragmatique n’applique pas tout à fond sans vérifier l’impact (CSP peut casser des intégrations si elle est mal réglée).
Isolation et segmentation
Si plusieurs sites partagent le même hébergement, un audit doit vérifier l’isolation (comptes séparés, permissions, séparation des pools PHP, pas de dossiers partagés en écriture). Sinon, la compromission d’un site peut contaminer les autres.
Sécurité de la base de données : comptes, privilèges et signes d’injection
La base de données est un actif critique : elle contient utilisateurs, hash de mots de passe, sessions, contenus, options, clés API parfois stockées en clair. Un audit de sécurité WordPress doit donc vérifier :
– Le compte MySQL utilisé par WordPress : il ne doit pas avoir plus de privilèges que nécessaire. Dans beaucoup de cas, il a des droits trop larges sur l’ensemble du serveur.
– Les identifiants de base : uniques, robustes, non réutilisés. Contrôlez aussi si des backups SQL circulent dans des dossiers accessibles publiquement.
– La table wp_options (ou son équivalent si préfixe personnalisé) : c’est souvent là que des injections persistantes se cachent (options autoload, code encodé, valeurs anormalement longues).
– Les utilisateurs WordPress : repérer des comptes inconnus, des élévations de privilèges, ou des changements d’e-mail et de mot de passe non expliqués.
Ajoutez une vérification de cohérence : un pic d’options autoload peut indiquer des ajouts anormaux. Ce point a aussi un impact performance, et performance et sécurité se croisent souvent (un site lent masque parfois des activités malveillantes en arrière-plan).
Plugins de sécurité, WAF, journalisation : vérifier l’efficacité réelle
Installer un plugin de sécurité ne suffit pas : l’audit doit vérifier qu’il est configuré, à jour, et surtout qu’il produit des signaux exploitables. Une sécurité silencieuse est rarement une sécurité efficace.
Contrôlez :
– Existence d’un WAF (au niveau serveur, CDN ou plugin) et son mode (détection vs blocage).
– Paramètres anti-brute force (verrouillage, CAPTCHA, listes d’autorisation si nécessaire).
– Journalisation des connexions (réussies/échouées), changements de fichiers, modifications des réglages sensibles.
– Alerting : qui reçoit les alertes, et sont-elles réellement consultées ? Un audit doit vérifier le circuit opérationnel (sinon, les alertes finissent ignorées).
– Rétention des logs et conformité : conserver assez longtemps pour investiguer, sans exposer de données sensibles inutilement.
Sauvegardes et restauration : le test qui révèle les failles cachées
La sauvegarde n’est pas un plus. C’est le filet de sécurité final. Dans un audit, on ne se contente pas de vérifier qu’un plugin de sauvegarde est activé : on vérifie qu’on sait restaurer, rapidement, proprement, et sans dépendre d’une seule personne.
Checklist minimale :
– Fréquence adaptée (site vitrine vs e-commerce vs média).
– Sauvegardes externalisées (pas uniquement sur le même serveur).
– Historique suffisant (rétention) et versions multiples.
– Sauvegarde fichiers + base de données + éventuellement configuration serveur.
– Procédure de restauration documentée et testée.
Le test clé : simuler une restauration sur un environnement de staging. Si vous cherchez une procédure simple et opérationnelle, consultez : Restaurer un Site en Moins de 10 Minutes.
Découvrez nos offres pour la maintenance de sites WordPress
Scanner les vulnérabilités… et interpréter les résultats sans faux positifs
Un audit sérieux combine des vérifications manuelles et des outils automatisés. Les scanners (vulnérabilités, malwares, configuration) font gagner du temps, mais ils peuvent produire des faux positifs ou manquer des attaques discrètes.
Dans votre démarche, privilégiez une approche en couches :
– Scanner des versions (plugins/thèmes) contre des bases de vulnérabilités connues.
– Analyse des fichiers (signatures + heuristiques) pour repérer obfuscation, appels suspects, fonctions dangereuses.
– Audit des configurations (HTTPS, headers, indexation de répertoires, endpoints exposés).
– Contrôle des logs (serveur et application) pour chercher des patterns d’attaque.
Pour compléter votre grille de contrôle avec des points actionnables, vous pouvez croiser avec des ressources externes comme Audit de sécurité WordPress : 7 vérifications à effectuer, puis adapter en fonction de votre contexte (trafic, données, contraintes métiers).
Contrôler les formulaires, l’upload et les points d’entrée business
Les formulaires de contact, inscriptions, demandes de devis, commentaires, et zones d’upload sont des surfaces d’attaque majeures. L’audit doit valider :
– Protection anti-spam et anti-bot (sans dégrader l’expérience utilisateur outre mesure).
– Validation côté serveur (pas seulement côté navigateur) : types de fichiers autorisés, taille, extension, contrôle MIME, renommage, stockage hors chemin exécutable si possible.
– Protection contre XSS et injections : champs texte, champs HTML, éditeurs WYSIWYG, shortcodes.
– Notifications : éviter d’exposer des informations sensibles (ex. e-mails contenant trop de détails techniques).
Si votre site gère des paiements, des comptes client ou des données personnelles, l’audit doit inclure une revue des pages critiques (checkout, espace client, endpoints AJAX) et des permissions associées.
Endpoints, REST API, XML-RPC et exposition involontaire
WordPress expose des endpoints utiles, mais qui peuvent être détournés selon la configuration. L’audit doit vérifier :
– REST API : quels contenus sont accessibles sans authentification ? Les types de contenus privés sont-ils correctement protégés ?
– XML-RPC : est-il nécessaire ? Si non, le désactiver peut réduire certains risques (brute force distribué, pingbacks). Si oui, le limiter et surveiller son usage.
– Pages de debug et endpoints de plugins : certains plugins laissent des routes ou pages d’admin accessibles de manière imprévue.
– Fichiers exposés : readme, changelog, listings de répertoires, endpoints de backup.
Un bon audit ne coupe pas tout automatiquement : il documente l’utilité et l’impact, puis applique une réduction progressive de l’exposition.
Performance et sécurité : les signaux faibles à ne pas ignorer
Une dégradation soudaine des performances peut être un symptôme : minage, spam, requêtes malveillantes, bots, ou surcharge due à une attaque par force brute. À l’inverse, une mauvaise performance peut pousser à des choix dangereux (désactiver des protections, laisser des caches mal configurés, exposer des répertoires). L’audit doit donc inclure un volet performance orienté sécurité.
Vérifiez les pics CPU/mémoire, l’origine des requêtes, les pages sollicitées, les erreurs 404 en rafale, et la volumétrie des requêtes POST. Pour structurer ce diagnostic, vous pouvez consulter : Comment Analyser la Vitesse de son Site Outils Méthode.
Et pour éviter les pièges classiques (plugins de cache empilés, images non optimisées, scripts tiers incontrôlés) qui nuisent autant à la stabilité qu’à la sécurité, cette ressource interne complète bien l’audit : Les Erreurs de Performance les Plus Fréquentes.
Cas particuliers : multilingue, staging, et environnements multiples
Les sites multilingues ajoutent souvent des plugins majeurs (traductions, SEO, gestion d’URLs, synchronisation de contenus) et multiplient les surfaces d’attaque : plus de routes, plus de contenu, plus d’éditeurs, parfois plus d’intégrations. Un audit doit vérifier que les langues additionnelles ne créent pas des chemins inattendus (ex. pages non protégées, redirections, duplicate content exploitable pour phishing, etc.).
Si votre site est concerné, anticipez aussi les risques techniques propres à ces configurations via : Multilingue Problèmes Techniques à Anticiper.
Autre point : les environnements de staging et de préproduction. Ils sont souvent moins protégés (mots de passe faibles, indexation active, plugins de debug, logs verbeux). Pourtant, ils contiennent parfois une copie de la base de production. Un audit doit vérifier l’accès (auth), l’indexation (noindex), et la séparation des secrets (clés API différentes entre staging et production).
Découvrez nos offres pour la maintenance de sites WordPress
Plan d’action : prioriser les corrections et prouver la réduction du risque
Un audit utile ne s’arrête pas à une liste de problèmes. Il produit un plan de remédiation priorisé selon : exploitabilité, impact, exposition, et effort. Une vulnérabilité critique sur un plugin exposé au public passe avant une amélioration hygiène à faible risque. Classez les actions en trois niveaux :
– Urgent (24–72h) : comptes suspects, malware, plugin vulnérable exploité, accès hébergeur non maîtrisé, sauvegarde inexistante.
– Important (1–2 semaines) : durcissement serveur, réduction des privilèges, suppression des composants inutiles, 2FA, WAF, logs.
– Amélioration continue (mensuel/trimestriel) : revue de dépendances, tests de restauration, contrôle des intégrations, surveillance.
Pour enrichir votre checklist et éviter les angles morts, vous pouvez confronter votre méthode à des approches structurées comme Les 7 Points Critiques que Personne ne Vérifie – AlmaWeb ou encore à un format plus opérationnel orienté contrôle rapide : Audit WordPress Express : 13 Points de Contrôle + Cas Réel.
Enfin, si vous cherchez une vue d’ensemble complémentaire (avec une démarche pas à pas) pour comparer vos résultats, cette ressource externe peut aider à valider votre couverture : Comment vérifier la sécurité de son site WordPress.
Mettre l’audit en routine : maintenance, monitoring et responsabilité
La sécurité WordPress n’est pas un événement ponctuel : c’est une routine. Le meilleur audit du monde perd de sa valeur si le site n’est pas maintenu, si les alertes ne sont pas lues, ou si les mises à jour sont repoussées sans processus.
Formalisez une cadence : revue hebdomadaire des mises à jour, contrôle mensuel des comptes et plugins, test de restauration trimestriel, et audit plus complet à intervalle régulier (ou après chaque changement majeur : nouveau thème, refonte, migration, ajout d’un plugin critique).
Si vous souhaitez externaliser tout ou partie de cette routine avec un cadre clair (mises à jour, surveillance, sauvegardes, interventions), vous pouvez consulter : Découvrez nos offres pour la maintenance de sites.
Un audit bien mené ne vise pas la perfection théorique. Il vise un site durablement maintenable, une surface d’attaque réduite, une détection plus rapide, et une capacité de restauration éprouvée. C’est ce trio (prévenir, détecter, récupérer) qui fait réellement la différence.
