Audit de sécurité WordPress : les points à vérifier

Un audit de sécurité WordPress consiste à vérifier les accès, les mises à jour, les fichiers, l’hébergement et les sauvegardes de votre site. Il sert à repérer les faiblesses et les signes d’intrusion, puis à classer les corrections selon leur urgence. Commencez par les comptes et les accès, avant d’examiner les composants et la configuration technique.

Contrôler les accès et les comptes WordPress

Les comptes sont le premier point à examiner : un accès oublié ou trop permissif peut permettre de modifier le site sans exploiter de faille technique.

Dans le tableau de bord WordPress, ouvrez Comptes > Tous les comptes et vérifiez chaque utilisateur, y compris ceux qui ne se connectent plus. Repérez notamment :

• Les comptes administrateurs génériques ou partagés.
• Les adresses e-mail obsolètes et les comptes inconnus.
• Les personnes qui disposent de droits supérieurs à leurs besoins.
• Les accès de prestataires dont la mission est terminée.

Appliquez le principe du moindre privilège : attribuez à chacun le rôle nécessaire à ses tâches, sans droits supplémentaires. Un rédacteur n’a pas besoin d’être administrateur. Avant de supprimer un compte, vérifiez à qui attribuer ses contenus et assurez-vous qu’il ne sert pas à une tâche encore active.

Renforcer la connexion

Pour chaque compte conservé, utilisez un mot de passe long, robuste et unique. Activez si possible la double authentification, en priorité pour les administrateurs, puis contrôlez les protections contre les tentatives répétées.

La limitation des tentatives de connexion sur WordPress réduit les possibilités d’attaque par force brute. Vérifiez aussi les mécanismes qui limitent l’énumération des utilisateurs : découvrir des identifiants valides peut faciliter des tentatives ciblées.

Ne pas oublier les accès à l’hébergement

L’audit doit couvrir les accès qui existent en dehors du tableau de bord :

• Le panneau d’hébergement et les comptes FTP ou SFTP.
• SSH et phpMyAdmin, lorsqu’ils sont utilisés.
• Le webmail et les adresses associées aux comptes sensibles.

Privilégiez des comptes individuels, des mots de passe uniques et, lorsque l’hébergeur le permet, une authentification forte. Révoquez les accès devenus inutiles : un compte d’hébergement compromis peut donner accès aux fichiers et à la base de données du site.

Examiner les mises à jour et les composants installés

Dans Tableau de bord > Mises à jour, contrôlez les mises à jour disponibles pour le cœur de WordPress, les thèmes et les extensions. Vérifiez également la version de PHP utilisée par l’hébergement et sa compatibilité avec les composants du site.

Ne vous limitez pas aux extensions actives. Un composant désactivé mais toujours installé peut rester exposé à certaines failles. Il peut aussi être réactivé par une personne ayant obtenu un accès administrateur.

Pour chaque thème ou extension, posez-vous les questions suivantes :

• Est-il encore utilisé et nécessaire au fonctionnement du site ?
• Reçoit-il des mises à jour et des correctifs ?
• Sa compatibilité est-elle annoncée pour votre configuration ?
• Son éditeur propose-t-il encore un support et une documentation ?

Avant une mise à jour ou une suppression, vérifiez que vous disposez d’une sauvegarde exploitable. Si possible, testez les changements sur une copie du site, puis contrôlez les pages et fonctions importantes.

La suppression demande aussi quelques précautions : une extension peut fournir des blocs, des shortcodes, des widgets, des scripts ou une intégration encore utilisée. Identifiez son rôle et prévoyez un retour arrière avant de la retirer. Le guide pour supprimer les extensions obsolètes sans risque détaille cette vérification.

Rechercher les fichiers et données suspects

Un site à jour peut déjà avoir été compromis. Complétez donc l’inventaire des composants par une recherche de modifications inattendues dans les fichiers, la base de données et les tâches planifiées.

Vérifier l’intégrité des fichiers

Examinez les dossiers et fichiers suivants :

• wp-content/uploads : recherchez les fichiers PHP suspects. Leur présence mérite une enquête, en particulier si leur exécution est possible.
• wp-config.php et .htaccess : repérez les ajouts inconnus, les redirections et les règles inhabituelles.
• wp-includes et wp-admin : recherchez les fichiers inattendus ou modifiés sans explication.
• Les fichiers du thème, notamment functions.php, header.php et footer.php : inspectez les ajouts suspects ou le code obfusqué.
• Les extensions indispensables, ou mu-plugins, qui peuvent contenir du code chargé automatiquement.

Contrôlez également les événements WP-Cron. Une tâche récurrente inconnue ou un appel externe suspect peut servir à relancer une action malveillante ou à réinstaller du code.

Ne supprimez pas un fichier uniquement parce que son nom vous semble étrange. Identifiez son origine et conservez les éléments nécessaires à l’analyse. En présence de signes de compromission, une procédure de nettoyage d’un site WordPress piraté permet de traiter l’infection et les accès associés.

Contrôler la base de données

La base contient notamment les comptes, les contenus et les réglages du site. Elle peut aussi stocker des clés d’API ou d’autres informations sensibles. Vérifiez :

• Les privilèges du compte MySQL utilisé par WordPress : ils doivent être limités à ce qui est nécessaire.
• La robustesse et l’unicité des identifiants de base de données.
• L’absence de sauvegardes SQL accessibles publiquement.
• Les comptes inconnus, les changements de rôle ou d’adresse e-mail inexpliqués.
• Les valeurs inhabituelles dans la table wp_options, dont le préfixe peut être différent sur votre site.

Dans cette table, des valeurs encodées, anormalement longues ou des options chargées automatiquement en nombre inhabituel méritent un examen. Ces indices ne prouvent pas une infection à eux seuls : comparez-les avec les extensions utilisées et les changements récents.

Vérifier l’hébergement et la configuration serveur

La sécurité du site dépend aussi de son environnement. Une configuration trop permissive peut faciliter l’exploitation d’une faille ou étendre ses conséquences à d’autres sites hébergés au même endroit.

Permissions, PHP et affichage des erreurs

Contrôlez les droits des fichiers et répertoires. Évitez notamment les répertoires en 777 et les fichiers critiques accessibles en écriture par tout le monde. Les permissions adaptées dépendent de l’hébergement ; l’objectif est de réserver l’écriture aux emplacements et aux comptes qui en ont besoin.

Vérifiez la version de PHP, les modules chargés et les fonctions activées. Une version obsolète ou une configuration inutilement permissive augmente l’exposition du site.

En production, les erreurs ne devraient pas s’afficher aux visiteurs. Le paramètre display_errors peut révéler des chemins de fichiers, des requêtes ou d’autres informations sensibles. Les erreurs doivent néanmoins rester consultables dans des journaux adaptés pour faciliter le diagnostic.

HTTPS, en-têtes et isolation

Assurez-vous que le certificat est valide et que les pages utilisent HTTPS. Vérifiez aussi la configuration des cookies sécurisés et des en-têtes de sécurité, notamment :

• HSTS, pour renforcer l’utilisation de HTTPS.
• X-Content-Type-Options, pour limiter certaines interprétations de contenu.
• X-Frame-Options ou une politique CSP, pour contrôler notamment l’intégration dans des cadres.
• Referrer-Policy, pour encadrer les informations transmises lors de la navigation.

Ces réglages doivent être adaptés au site. Une politique CSP trop restrictive, par exemple, peut empêcher le fonctionnement de scripts ou de services tiers.

Si plusieurs sites partagent un hébergement, vérifiez leur isolation : comptes séparés, permissions appropriées, séparation des pools PHP lorsque l’hébergement le permet et absence de dossiers partagés en écriture sans nécessité. Une faille sur un site ne doit pas donner facilement accès aux autres.

Tester les protections et surveiller les signaux d’alerte

Une extension de sécurité installée mais mal configurée ne suffit pas. Vérifiez qu’elle est à jour, que ses protections sont actives et que les alertes arrivent à une personne qui les consulte.

Pare-feu, journaux et scanners

Le pare-feu applicatif, ou WAF, peut être fourni par le serveur, un CDN ou une extension. Contrôlez son mode : un outil qui détecte les requêtes suspectes ne les bloque pas nécessairement. Vérifiez aussi les réglages anti-brute force, les éventuels CAPTCHA et les listes d’autorisation nécessaires à votre activité.

Les journaux doivent aider à comprendre ce qui se passe sur le site. Selon les outils disponibles, examinez :

• Les connexions réussies et échouées.
• Les changements de fichiers et de réglages sensibles.
• Les erreurs et requêtes inhabituelles côté serveur.
• Les alertes émises, leurs destinataires et leur durée de conservation.

Conservez suffisamment d’historique pour pouvoir enquêter, sans exposer inutilement de données sensibles. Pour approfondir ce point, consultez le guide sur le fonctionnement d’un pare-feu WordPress.

Les scanners complètent ces contrôles manuels. Ils peuvent comparer les versions installées à des vulnérabilités connues, rechercher des signatures de malware ou signaler des configurations exposées. Interprétez leurs résultats avec prudence : un outil peut produire des faux positifs ou manquer une attaque.

Repérer les anomalies de performance

Un ralentissement soudain n’est pas forcément une attaque, mais il justifie une vérification. Une activité malveillante, des bots ou des tentatives de connexion répétées peuvent notamment augmenter la charge.

Examinez les pics de CPU et de mémoire, l’origine des requêtes, les pages les plus sollicitées, les séries d’erreurs 404 et le volume de requêtes POST. Croisez ces observations avec les journaux et les changements récents avant de modifier les protections ou le cache.

Contrôler les formulaires et les points d’entrée exposés

Les formulaires de contact, les commentaires, les inscriptions et les zones d’envoi de fichiers acceptent des données venant de l’extérieur. Ils méritent donc un contrôle spécifique, en particulier si le site gère des comptes clients ou des paiements.

Vérifiez que les protections anti-spam et anti-bot fonctionnent sans empêcher les utilisateurs légitimes de terminer leurs démarches. Testez les formulaires et assurez-vous que les notifications ne transmettent pas plus d’informations sensibles que nécessaire.

Pour les fichiers envoyés, la validation doit aussi avoir lieu côté serveur, et non seulement dans le navigateur. Contrôlez les types et tailles autorisés, les extensions, le type MIME, le renommage et, si possible, le stockage hors d’un chemin exécutable.

Examinez également la protection des champs texte, du contenu HTML, des éditeurs et des shortcodes contre les injections et les scripts indésirables. Pour un site marchand, vérifiez les permissions des pages de paiement, de l’espace client et des points d’entrée AJAX.

REST API, XML-RPC et fichiers publics

Les points d’entrée de WordPress peuvent être utiles aux extensions et aux applications connectées. L’objectif n’est pas de tout désactiver, mais de vérifier ce qui est exposé et pourquoi.

• REST API : contrôlez les contenus accessibles sans authentification et la protection des données privées.
• XML-RPC : vérifiez s’il est utilisé. S’il n’est pas nécessaire, sa désactivation peut réduire certains risques ; sinon, limitez et surveillez son usage.
• Routes et pages d’extensions : recherchez les pages de diagnostic ou d’administration accessibles de manière imprévue.
• Fichiers et dossiers publics : vérifiez les sauvegardes, les listings de répertoires et les fichiers de documentation exposés.

Avant de restreindre un accès, identifiez les applications et fonctionnalités qui en dépendent. Appliquez les changements progressivement et testez le site après chaque modification.

Sites multilingues et environnements de test

Sur un site multilingue, vérifiez les extensions de traduction, les routes, les redirections et les droits des éditeurs dans chaque langue. Une page protégée dans une langue doit bénéficier d’une protection cohérente dans les autres.

Contrôlez aussi les sites de staging et de préproduction. Ils peuvent contenir une copie des données réelles tout en étant moins surveillés. Protégez leur accès par authentification, vérifiez leur indexation et séparez les clés d’API de celles de la production. Désactivez les outils de débogage et les journaux trop détaillés lorsqu’ils ne sont plus nécessaires.

Tester les sauvegardes et organiser les corrections

Une sauvegarde n’est utile que si elle peut être restaurée. Vérifiez que le dispositif couvre les fichiers et la base de données, ainsi que la configuration serveur lorsqu’elle est nécessaire à la reprise.

Adaptez la fréquence des sauvegardes à l’activité du site : une boutique qui reçoit des commandes n’a pas les mêmes besoins qu’un site vitrine peu modifié. Conservez plusieurs versions, avec un historique suffisant, et au moins une copie en dehors du serveur du site.

Documentez la procédure de restauration et testez-la sur un environnement de staging. Contrôlez ensuite les pages, les comptes et les fonctions principales. Ce test permet de vérifier que les fichiers et la base correspondent et que la procédure ne dépend pas d’une seule personne.

Établir un plan d’action

À la fin de l’audit, consignez chaque anomalie, son impact possible, son exposition et la correction prévue. Classez les actions par priorité :

1. Urgent : comptes suspects, malware, vulnérabilité exploitée, accès à l’hébergement non maîtrisé ou absence de sauvegarde.
2. Important : réduction des privilèges, suppression des composants inutiles, double authentification, durcissement serveur, WAF et journaux.
3. Suivi régulier : revue des dépendances et des intégrations, surveillance et tests de restauration.

Les délais dépendent du risque réel et du contexte du site. Corrigez d’abord ce qui est exposé et exploitable, puis vérifiez que chaque changement fonctionne comme prévu.

Pour maintenir le résultat, prévoyez une revue hebdomadaire des mises à jour, un contrôle mensuel des comptes et extensions, ainsi qu’un test de restauration trimestriel. Répétez un audit plus complet après une refonte, une migration ou l’ajout d’un composant important. Une maintenance WordPress régulière permet d’inscrire ces vérifications dans une routine.

Questions fréquentes

Article rédigé avec l’aide d’une IA à partir des sources citées et de notre pratique de la maintenance WordPress. Notre méthode éditoriale.