Quand un site WordPress est compromis, on cherche souvent un “truc” spectaculaire: un script caché, un plugin inconnu, une porte dérobée qui ne se voit qu’à l’examen des fichiers. Dans la pratique, la plupart des attaques réussies laissent aussi un autre indice: des fichiers qui ont changé sans raison légitime. C’est là que la vérification d’intégrité, via des checksums, devient un réflexe solide.
Vérifier des checksums, ce n’est pas seulement “être parano”. C’est obtenir une preuve technique: pour un ensemble de fichiers attendus, on calcule une empreinte (hash) et on la compare à une valeur de référence. Si l’empreinte ne correspond pas, quelque chose a probablement modifié le contenu, même si la page d’administration semble normale.
Dans cet article, je vais détailler comment penser la vérification d’intégrité pour renforcer sécurité WordPress, ce que vous pouvez réellement contrôler, ce qui est difficile, et comment éviter les faux positifs qui finissent par vous faire ignorer les alertes.
L’idée simple derrière les checksums
Un checksum, souvent réalisé avec un algorithme de type SHA-256 (ou équivalent), transforme un contenu de fichier en une “signature” numérique. Deux fichiers différents donnent quasi toujours des signatures différentes. Et surtout, si un attaquant modifie ne serait-ce qu’une ligne, la signature change.
Le point clé: une checksum n’est utile que si vous disposez d’une référence fiable. Cette référence peut venir de:
- la documentation de votre version (par exemple pour le cœur WordPress), un fichier manifest généré lors d’un déploiement maîtrisé, une sauvegarde connue comme saine, ou un registre interne de checksums conservé dans votre processus d’intégration et de mise en production.
Sans référence, vous avez juste une empreinte, pas un test.
Ce que les checksums peuvent et ne peuvent pas faire
Dans un contexte réel, il faut garder un peu de nuance. Les checksums sont excellents pour détecter une modification de fichiers, mais ils ne vous disent pas forcément “qui” ni “pourquoi”.
Voici le cadre mental que j’utilise quand je mets en place une vérification.
Ils sont très efficaces pour
Pour le noyau WordPress, par exemple, vous pouvez comparer des fichiers core attendus contre des valeurs de référence. Si quelqu’un a injecté du code dans un fichier du cœur, la checksum ne matchera plus.
Pour des thèmes et plugins “standard”, c’est possible si vous avez une source de confiance, ou si vous gérez ces composants via un déploiement répétable. Dans des environnements sérieux, les assets sont souvent déployés depuis une pipeline, et les checksums peuvent être enregistrés à ce moment-là.
Ils sont moins efficaces pour
Si un site est rempli de modifications légitimes (surcharge de fichiers, patchs manuels, customisation directe du plugin), la vérification stricte devient rapidement bruyante. Et un attaquant peut viser des fichiers très spécifiques, par exemple en ajoutant un fichier image mal nommé ou un script dans un dossier qui n’est pas couvert par votre test.
Autre limite: un attaquant peut aussi agir au niveau “base de données” plutôt qu’au niveau “fichiers”. Les checksums ne détecteront pas un changement dans des options WordPress, des enregistrements utilisateurs, ou des tables modifiées. On peut alors compléter avec d’autres contrôles, mais ça sort du sujet principal ici.
Pourquoi vérifier l’intégrité revient souvent au moment opportun
Une anecdote revient souvent dans les équipes qui maintiennent des sites WordPress. J’ai déjà vu une alerte “activité suspecte” qui se révélait finalement être une manipulation manuelle pendant une migration. Les logs disaient “douteux”, mais le contenu semblait inchangé. À l’inverse, j’ai aussi vu des incidents où l’administration n’affichait aucun signe, et pourtant plusieurs fichiers du cœur avaient été modifiés. Dans les deux cas, la différence, c’était la présence ou l’absence d’un contrôle d’intégrité simple.
Quand vous avez un check de cohérence entre “ce que vous attendez” et “ce qui est réellement sur le serveur”, vous évitez deux extrêmes: 1) paniquer pour des symptômes vagues, 2) rater des modifications réelles parce qu’elles sont silencieuses.
Renforcer sécurité WordPress avec une stratégie de référence
Le piège classique, c’est de vouloir vérifier tout et partout dès le départ. Le résultat, ce sont des alertes impossibles à trier: vous finissez par ignorer. Mieux vaut démarrer avec un périmètre clair, puis élargir.
Concrètement, je conseille de poser trois questions:
Première question: quel “référentiel” vous faites confiance pour obtenir vos checksums de référence? Si la source est fragile (un dossier copié depuis un serveur déjà suspect), votre test perd une grande partie de sa valeur.
Deuxième question: quels fichiers ont des chances d’être modifiés de façon normale? Si vous faites du développement directement sur le serveur en modifiant des templates à la main, vous devez décider si cette pratique doit rester, ou si vous allez la remplacer par un déploiement contrôlé.
Troisième question: à quelle fréquence vous vérifiez? Une vérification “au coup par coup” ne crée pas un filet. À l’inverse, une vérification trop fréquente sur un gros site peut devenir lente et générer des interruptions. Le bon rythme dépend de la taille et de votre mode d’administration.
Vérifier l’intégrité du cœur WordPress: l’approche la plus robuste
Le cœur WordPress est un cas particulier, parce que les fichiers sont versionnés. Si vous utilisez un environnement standard, vous pouvez comparer votre installation à des checksums “attendus” pour la version exacte.
Dans l’écosystème WordPress, l’outil WP-CLI est souvent utilisé pour ce type de vérification. Selon votre installation, vous pouvez exécuter une commande de vérification des checksums du core, et obtenir un résultat explicite: fichiers modifiés, fichiers manquants, ou état conforme. Si vous n’avez jamais fait l’exercice, c’est le moment idéal: vous réalisez un test avant incident, puis vous voyez ce que produit un check “normal”.
Je le fais systématiquement dans les audits, car c’est un excellent indicateur de base. Si le core passe proprement, vous savez que le problème éventuel ne vient pas d’une altération du cœur. Si le core échoue, la priorité devient claire: investigation et restauration, puis seulement après, analyse de la cause.
Gestion des faux positifs sur le core
Il y a des cas où une vérification échoue sans intrusion. Par exemple:
- mise à jour interrompue, déploiement incomplet, conflit de versions (un fichier reste de l’ancienne version), restauration partielle après une panne.
Le point important est que ces scénarios restent actionnables. Une checksum qui ne correspond pas n’implique pas automatiquement “piratage”, mais elle implique “écart à réparer”.
Et pour les thèmes et plugins, comment faire?
C’est là que la vérification devient plus délicate. WordPress core a un référentiel stable, mais plugins et thèmes changent en permanence. Certains sont auto-modifiés (minification côté admin, génération de assets, caches). D’autres sont packagés différemment selon la source (zip officiel, fork, déploiement maison).
Vous avez trois options, du plus simple au plus structurant.
Option 1: vérifier seulement ce qui est contrôlé
Vous limitez le périmètre à des éléments que vous considérez maîtrisés. Par exemple, vous vérifiez uniquement les fichiers core, puis vous surveillez les changements de plugins et thèmes via des contrôles complémentaires (listes, dates de modification, contrôle de fichiers spécifiques, etc.).
Cette approche est souvent suffisante pour démarrer, surtout quand votre priorité est de “stopper l’hémorragie” plutôt que d’installer une usine à gaz.
Option 2: construire un référentiel de checksums au déploiement
Si vous déployez vos plugins et thèmes via une pipeline (même artisanale, tant que c’est reproductible), vous pouvez calculer des hashes à l’instant où vous déployez depuis une source fiable, puis enregistrer ces valeurs quelque part (un fichier dans le dépôt, une base de données, ou un stockage de configuration).
Ensuite, à intervalles réguliers, vous recalculez et vous comparez.
Le bénéfice, c’est que vous ne dépendez plus d’un “zip” ou d’un téléchargement manuel. Vous dépendez de votre processus.
Le coût, c’est que vous devez accepter la discipline: si quelqu’un modifie un fichier sur serveur, il cassera le contrat et devra passer par le déploiement.
Option 3: accepter des exceptions documentées
Dans certains cas, vous aurez des fichiers qui changent “normalement” (generation de minified assets, caches, fichiers de traduction chargés, uploads). Une checksum stricte devient ingérable.
Une solution pratique consiste à exclure certains dossiers de votre test (notamment les répertoires de contenus générés, comme uploads) et à définir une règle sur ce qui est considéré “intouchable”. C’est un arbitrage, et je le recommande, mais avec prudence. Exclure trop large, c’est laisser de la surface à l’attaque. Exclure au bon niveau, c’est garder l’outil utile.
Calculer des checksums sans vous piéger vous-même
Une vérification d’intégrité, ce n’est pas seulement “lancer une commande”. Il faut aussi éviter les erreurs de méthode qui rendent la comparaison inutile.
Quelques points concrets que j’ai appris à répéter:
La checksum dépend du contenu, pas du chemin. Si vous reconstruisez ou reformatez des fichiers (ligne endings, encodage différent), vous pouvez changer l’empreinte même si le code “fonctionnel” semble identique. Sur les sites qui ont des fichiers générés dans différents environnements, c’est un vrai sujet.
La checksum doit être comparée à une référence pour la même version et le même état attendu. Un plugin mis à jour et déployé partiellement, par exemple, peut faire échouer la vérification alors que “la plupart” est correcte. Dans ce cas, l’erreur vous guide vers le fichier manquant ou différent, ce qui accélère le diagnostic.
Et surtout, vos checks doivent être exécutés dans un environnement qui a du sens. Si vous testez un serveur sans connaître l’historique de déploiement, vous risquez de confondre “déploiement atypique” et “intrusion”.
Un petit protocole de vérification utile, même sans automatisme
Plutôt que d’installer une usine tout de suite, vous pouvez mettre en place un protocole simple qui donne des résultats exploitable.
Voici un modèle que vous pouvez adapter. L’idée n’est pas de couvrir 100% de votre site, mais de créer un filet fiable sur les éléments critiques.
- Vérifier le core WordPress avec votre outil (par exemple via WP-CLI si présent). Noter la version exacte de WordPress et la date de la dernière mise à jour déployée. Vérifier ensuite les fichiers que vous considérez “statiques” (ceux qui changent rarement), en vous appuyant sur un référentiel si vous en avez un. Contrôler les journaux d’accès et les événements d’administration sur la période précédant l’alerte. Si des écarts sont trouvés, planifier une restauration depuis une source saine avant toute “expérience” supplémentaire sur le site.
Je sais que la dernière ligne paraît évidente, mais en incident, beaucoup de gens “essaient” d’abord des choses sur le serveur. Avec des fichiers altérés, ça brouille la preuve. Une restauration propre d’abord, même si c’est inconfortable, vous rend la suite plus simple.
Interpréter les résultats quand des checksums ne matchent pas
Un échec de checksum n’est pas un verdict unique. Il indique un écart. La lecture dépend du contexte.
Si seuls quelques fichiers échouent, commencez par regarder lesquels. Souvent, il s’agit de fichiers du core altérés, ou de scripts ajoutés ailleurs, ou de caches générés. Une liste de fichiers en rouge ou un message “modifié” vous donne un point d’entrée.
Si la plupart des fichiers sont modifiés, c’est le signal d’un problème plus large: déploiement corrompu, transfert incomplet, ou compromission avec impact étendu. Dans ce cas, restaurer à partir d’une référence propre devient généralement plus rationnel que de “réparer fichier par fichier”.
Si des fichiers sont “manquants”, la question devient: est-ce qu’on a déjà fait un remplacement, une mise à jour interrompue, ou un nettoyage partiel? Les intrusions qui suppriment peuvent aussi créer https://gardewp.fr/securite-wordpress/ ce symptôme, donc il faut recouper, avec dates de modification, et avec l’historique d’opérations.
Mettre en place une routine: vérification périodique et garde-fous
La valeur d’un contrôle d’intégrité augmente quand il devient une habitude. Sur un site vivant, l’idéal est d’avoir une vérification:
- avant une mise à jour, après une mise à jour, puis à fréquence fixe, par exemple mensuelle, ou après tout changement majeur (nouveau plugin, changement de thème, migration).
Je ne donne pas une fréquence universelle, parce qu’elle dépend de la taille, du temps nécessaire à calculer les hashes, et surtout de votre tolérance au changement. Mais j’ai vu des organisations gagner en sérénité dès qu’elles ont arrêté de vérifier “uniquement quand ça va mal”.
Une approche pratique après chaque déploiement
Voici une séquence courte que j’utilise quand je fais un déploiement contrôlé sur un environnement WordPress:
Déployer depuis la source de confiance, pas depuis le serveur précédent. Lancer une vérification d’intégrité du core. Vérifier le statut des plugins et thèmes (activation, mises à jour cohérentes avec la version déployée). Garder le résultat du check (capture, log, ou fichier) pour comparer au prochain passage.Cette routine réduit énormément le temps passé à chercher “ce qui a changé”. Vous avez déjà une baseline.
Sécurité en profondeur: checksums et autres contrôles qui se complètent
Vérifier l’intégrité ne remplace pas une vraie stratégie de sécurité WordPress. C’est un outil parmi d’autres, mais il a une particularité: il attaque le problème à la racine, au niveau du fichier réellement présent.
En pratique, je combine souvent checksums et contrôles “autour”:
- durcissement des permissions fichier, suivi des comptes administrateurs et des connexions, gestion stricte des droits d’écriture dans les zones sensibles, limitation de l’édition de fichiers depuis l’interface, et surveillance des modifications dans le temps.
Le bon sens ici, c’est que chaque contrôle a ses angles morts. Les checksums ont moins d’angles morts côté fichiers que côté base de données, donc vous couvrez mieux l’ensemble en combinant.
Edge cases qui reviennent souvent
Environnements où les fichiers changent pour de “bonnes” raisons
Sur certains hébergements, des optimisations peuvent modifier des fichiers au moment de la génération d’assets. Si vous activez des options de cache agressives, ou si un outil de “hardening” modifie les fichiers, vous pouvez déclencher des écarts.
Dans ce cas, la solution n’est pas de désactiver la sécurité. C’est de clarifier le processus: quel composant modifie quoi, et quand. Ensuite, vous adaptez vos référentiels et vos exclusions.
Conversions de fin de ligne, encodage et diff subtil
Un même fichier “fonctionnel” peut produire une checksum différente après un passage par un éditeur avec des transformations de fin de ligne, ou un transfert en mode différent. J’ai déjà vu des équipes perdre du temps parce que le référentiel avait été généré sur un système avec une normalisation différente.
La conséquence: assurez-vous que la source de référence et le serveur testé suivent des conventions cohérentes.
Le problème des référentiels obsolètes
Un référentiel de checksums “de l’année dernière” n’a aucune valeur si vous êtes aujourd’hui sur une autre version de WordPress ou après mise à jour de plugins. Le test échoue, mais vous ne savez pas si l’échec signale un compromis ou une simple divergence de version.
Donc, chaque référence doit être associée à une version exacte et idéalement à un timestamp de déploiement.
Une liste de décisions utiles avant de démarrer
Avant de lancer la première vérification, prenez le temps de choisir votre cadre. Ce que je veux éviter, c’est l’effet “alert fatigue”, l’accumulation d’alarmes que personne ne trie.
Voici les décisions à arrêter (et je les traite comme un mini cahier des charges interne):
- Qu’est-ce que vous considérez comme “fichiers à valeur” (core, thèmes et plugins statiques, fichiers de configuration)? Quelle source vous utilisez pour la référence (procédé de déploiement, sauvegarde saine, référentiel versionné)? Quelles exclusions sont acceptables (uploads, caches, dossiers générés) et pourquoi? Qui est responsable de la maintenance du référentiel (une personne, une équipe, un pipeline)? Que faites-vous quand un check échoue (restauration, investigation, mise en quarantaine, rotation des identifiants)?
Si vous répondez à ces questions, les checksums deviennent un outil opérationnel, pas une activité ponctuelle.
Conclusion sans formalisme: faire des checksums un réflexe utile
Vérifier l’intégrité des fichiers avec des checksums, c’est une façon très concrète de réduire la surface d’incertitude. Vous ne dépendez plus seulement de “ça a l’air normal” ou de “j’ai l’impression que”. Vous testez ce qui est réellement sur le serveur, et vous obtenez une preuve de divergence.
Le cœur WordPress offre un meilleur terrain de jeu, parce que les versions se raisonnent facilement. Thèmes et plugins demandent plus de discipline, soit via un déploiement reproductible, soit via un référentiel interne. Et même quand la checksum ne vous dit pas “c’est tel attaquant”, elle vous donne un signal d’action rapide, surtout quand vous avez l’habitude d’enregistrer vos résultats après chaque mise à jour.
Si vous cherchez un premier pas pour renforcer sécurité WordPress sans vous enfermer dans une complexité excessive, commencez par un contrôle du core, puis construisez progressivement une routine. Dans la plupart des environnements, c’est ce chemin, étape par étape, qui finit par protéger réellement, parce qu’il tient dans le temps.