Quand on parle de “scanner malware WordPress”, on pense souvent au moment où l’on lance un outil et où, très vite, on veut une réponse claire. Le vrai travail commence après le scan, même si celui-ci est rassurant. Un site WordPress n’est pas fragile parce qu’il “est WordPress”. Il devient fragile quand la surface d’attaque s’élargit, quand PHP est trop permissif, quand le serveur autorise des comportements inutiles, ou quand des composants risquent d’être interprétés là où ils ne devraient pas l’être.
Dans cet article, je vais vous montrer comment je procède pour durcir la configuration PHP et le serveur, dans une logique pragmatique: réduire les options qui facilitent l’exécution de code, limiter les chemins que les attaquants aiment explorer, et conserver assez de souplesse pour que votre thème, vos plugins et vos mises à jour continuent de fonctionner. Le but n’est pas de “tout verrouiller jusqu’à casser”. Le but est de rendre l’exploitation plus coûteuse et plus difficile, tout en gardant une exploitation légitime possible.
Ce que révèlent vraiment les scans, et ce qu’ils ne disent pas
Un scan de type “scanner malware WordPress” met généralement en lumière des fichiers modifiés, des signatures connues, des incohérences dans des répertoires inattendus, parfois des ajouts de tâches planifiées ou des scripts cachés dans des uploads. C’est utile. Mais un scan n’a pas la vision complète des moyens d’attaque.
Il y a deux scénarios fréquents:
1) Le scan trouve un indicateur, mais le serveur reste configuré de façon à ce que ça puisse revenir. Vous nettoyez, puis quelqu’un ré-exploite une faiblesse similaire, parce que PHP ou la configuration serveur laissent trop de liberté.
2) Le scan ne trouve rien d’évident, mais un vecteur reste exploitable: permissions trop larges, exécution de scripts dans des zones qui ne devraient pas, fonctions PHP dangereuses activées, erreurs de configuration .htaccess ou directives serveur qui autorisent l’exécution indirecte.
Autrement dit, même après un scan “propre”, la sécurité dépend beaucoup plus de l’environnement d’exécution que du seul contenu du site. C’est là que la durcissement PHP et serveur devient un levier durable.
Partir du bon angle: l’exploitation a besoin de conditions
D’expérience, une infection WordPress arrive rarement par magie. Elle s’appuie sur un enchaînement: accès initial (mot de passe faible, plugin vulnérable, thème compromis, mauvaise segmentation), puis exécution de code via un chemin technique précis. Les attaquants adorent quand l’environnement PHP est permissif, notamment quand il permet des chargements dynamiques, quand l’écriture et l’exécution sont trop proches, ou quand des contenus téléchargés peuvent être interprétés.
Le durcissement vise à casser ces conditions, ou au minimum à compliquer le parcours:
- rendre l’exécution de scripts moins probable dans les répertoires non prévus; réduire les fonctions PHP inutiles ou dangereuses; forcer des modes de fonctionnement plus sûrs (disable de certaines extensions, restrictions réseau, contrôle des chemins); renforcer les permissions et la cohérence des droits.
Vous ne devez pas traiter ce travail comme un exercice “théorique”. Traitez-le comme une hygiène technique, que vous pouvez auditer et répéter.
Avant de toucher à PHP: sécuriser sans casser
Avant de modifier php.ini, des valeurs FPM ou des directives PHP dans .htaccess, je conseille une phase de préparation courte mais réelle:
- Vérifiez si vous avez un staging. Si vous n’en avez pas, au moins prévoyez une fenêtre de maintenance et un rollback possible (copie de configuration et sauvegarde du code). Identifiez le mode d’exécution actuel: Apache + mod_php, Apache + PHP-FPM, Nginx + PHP-FPM, ou autre. Les directives ne se traduisent pas pareil. Repérez les plugins et fonctionnalités qui exigent des comportements particuliers (par exemple génération d’images, import CSV, webhooks, connecteurs, API externes). Si vous coupez trop, vous aurez des erreurs “étranges” difficiles à diagnostiquer.
Ce point compte énormément. La sécurité n’existe pas seule, elle doit s’accorder avec vos besoins.
Durcir PHP: les réglages qui changent le jeu
Le durcissement PHP se joue sur trois axes: limiter ce que PHP peut faire, réduire ce qu’il peut lire/écrire, et éviter les comportements qui facilitent l’exécution indirecte.
Réduire l’empreinte et les comportements inutiles
Dans beaucoup d’environnements, certaines fonctions PHP restent activées alors qu’elles ne sont pas nécessaires au fonctionnement d’un site standard. https://gardewp.fr/nettoyage-malware-wordpress/ Vous pouvez agir sur deux niveaux: désactiver des fonctions via disable_functions (si supporté), et couper des extensions ou réglages via php.ini ou le contrôle de votre runtime.
Je parle volontairement de “si supporté”, parce que selon votre hébergement, vous n’avez pas la même main. En mutualisé, vous ne pourrez pas toujours toucher à php.ini globalement. En VPS ou serveur dédié, vous avez plus de contrôle.
Voici les principes que j’applique:
- désactiver les fonctions de création de processus ou d’écriture risquée si elles ne sont pas nécessaires; limiter les téléchargements et téléchargements dynamiques; durcir l’exécution des scripts dans des contextes non attendus.
Plutôt que de vous noyer dans une liste énorme de directives, je préfère vous guider sur le raisonnement et les réglages “typiques” à explorer, en vérifiant la compatibilité.
Choisir les bons modes: error reporting et display_errors
Une erreur “affichée” dans un contexte de production peut donner des indices: chemins, versions, structure de répertoires, détails d’extensions. Sur un site WordPress, ces indices peuvent accélérer l’attaque.
Je règle généralement:
- display_errors à off en production; log_errors à on (pour tracer, pas pour divulguer); le reporting d’erreurs selon un niveau raisonnable.
Le trade-off est simple: vous perdez l’affichage direct pour vos visiteurs, mais vous récupérez des journaux. Si vous avez un système de logs (ou un accès aux logs serveur), vous gagnez en visibilité sans exposer d’informations.
Vérifier et contraindre open_basedir
Open_basedir est un outil utile quand il est correctement appliqué. Il empêche PHP d’accéder à des chemins hors d’une liste autorisée. Cela peut empêcher un code malveillant de sortir de l’arborescence attendue.
Le piège, c’est que WordPress, selon la configuration, peut utiliser plusieurs chemins: uploads, thèmes, plugins, caches, uploads chiffrés ou stockage externe, parfois des flux vers d’autres emplacements (selon l’usage). Si vous appliquez open_basedir trop strictement, vous aurez des erreurs. Dans ce cas, mieux vaut corriger la liste de chemins autorisée progressivement plutôt que de passer en force.
Durcir les limites et timeouts
Les attaquants exploitent aussi des failles de ressources: tentatives de déni de service, scripts qui tournent longtemps, ou traitements coûteux déclenchés de manière indirecte.
Sur PHP, je regarde systématiquement:
- memory_limit: un plafond raisonnable, compatible avec votre taille de site et vos plugins; max executiontime et max inputtime: valeurs cohérentes avec vos traitements; upload maxfilesize et post maxsize: limiter ce qui peut être envoyé, tout en restant cohérent avec vos besoins.
Ce n’est pas seulement “anti-DOS”. C’est aussi un garde-fou contre des comportements inattendus. Par exemple, certains plugins ou scripts peuvent provoquer des pics si le serveur est déjà sous contrainte.
Contrôle d’exécution via .htaccess et règles web
Sur Apache, les règles dans .htaccess (ou la configuration vhost) ont un impact direct sur la sécurité. Même sans entrer dans tous les détails de syntaxe, l’idée est claire: ne pas laisser des fichiers non destinés à PHP être interprétés.
Dans WordPress, un point revient souvent après incident: des fichiers “bizarres” créés dans des répertoires d’uploads. Si la configuration web interprète accidentellement PHP dans ces zones, le risque augmente fortement.
Je vérifie donc:
- que PHP n’est interprété que là où il faut (typiquement fichiers .php); que les extensions alternatives ou contenus “camouflés” ne sont pas interprétés; que les répertoires sensibles ne sont pas exposés.
Dans certains environnements, vous pouvez aussi bloquer l’exécution dans les dossiers d’uploads via directives spécifiques. C’est un excellent levier, tant que votre média et votre pipeline d’images ne nécessitent pas d’exécution serveur dans ces zones.
Permissions et cohérence: le volet silencieux de la sécurité
La durabilité de la sécurité dépend beaucoup des droits système. Un serveur bien configuré, mais avec des permissions laxistes, permet à un incident de s’installer plus facilement.
Quelques règles simples que j’ai vues fonctionner dans la durée:
- garder les répertoires d’édition Web avec des droits minimaux; séparer les droits d’exécution et les droits d’écriture quand c’est possible; vérifier l’absence de fichiers exécutables inattendus dans des répertoires non prévus.
Le “bon” réglage dépend de votre stack, mais le principe reste le même: limiter qui peut écrire, limiter où ça peut s’écrire, et limiter ce qui peut s’exécuter.
Une méthode de durcissement sans panique: vérifier, appliquer, valider
Je propose une démarche en trois temps, car elle évite de se retrouver avec un site KO et aucune idée de ce qui a causé la panne.
Étape 1: établir une base de fonctionnement
Avant toute modification, je collecte des indices:
- versions PHP et configuration actuelle (les directives relevantes); type de serveur web, et existence de règles .htaccess; logs récents (erreurs PHP, erreurs Apache/Nginx); liste des endpoints et fonctions susceptibles d’utiliser des capacités “spéciales”.
Ce travail peut sembler “administratif”, mais il fait gagner des heures quand vous devez diagnostiquer un problème.
Étape 2: durcir par petites touches
Je durcis ensuite sur des axes indépendants, en faisant valider entre chaque. Par exemple, commencer par l’information divulguée (display errors), puis enchaîner sur les accès (openbasedir), puis sur l’exécution (règles web), puis sur des limites ressources.
Le but est d’identifier le point de rupture si ça casse.
Étape 3: valider côté application et côté sécurité
Vous ne validez pas seulement “ça charge la page”. Vous validez aussi des actions réelles: connexion au back-office, sauvegarde d’un brouillon, upload d’une image, génération d’un shortcode si vous en utilisez.
L’objectif: ne pas confondre “WordPress fonctionne” avec “WordPress a encore exactement les mêmes capacités qu’avant”.
Check rapide avant de verrouiller PHP à fond
Voici les contrôles que je fais presque systématiquement avant de passer en mode “verrouillage”. Cette liste reste volontairement courte pour rester praticable.
- Vérifier le type d’hébergement (mutualisé, VPS, FPM, mod_php), car certaines directives sont impossibles à appliquer. Contrôler si des plugins nécessitent des appels réseau sortants ou des traitements longs (import, indexation, webhooks). Vérifier les répertoires d’uploads et leur comportement en exécution (surtout sur Apache via .htaccess). Configurer les logs (PHP et serveur) de manière à pouvoir diagnostiquer après modification. Préparer un plan de rollback (au minimum sauvegarde des fichiers et des paramètres web).
Durcissement serveur: ce que je regarde en priorité après un scan
Quand un site a déjà eu un incident, je ne me contente pas de réparer. Je sécurise la voie d’entrée et la voie d’exécution. Sur le serveur, ça se traduit par quelques leviers concrets.
Réduire l’exposition réseau et limiter l’attaque automatisée
Au niveau réseau, vous pouvez réduire l’attaque opportuniste en contrôlant:
- l’accès aux endpoints sensibles; la limitation de taux sur les tentatives de connexion; le filtrage des requêtes suspectes (selon vos outils de pare-feu ou reverse proxy).
Je ne liste pas une solution unique ici, car selon votre environnement (cloud, reverse proxy, WAF, firewall), les moyens diffèrent. Mais le principe reste constant: faire perdre du temps aux scripts automatisés.
Bloquer ce qui ne doit pas être servi
L’erreur classique, c’est d’exposer des fichiers de configuration, des dumps, ou des répertoires “oubliés” suite à un déploiement.
Je fais un audit simple:
- quels dossiers contiennent des fichiers non attendus; quels types de fichiers peuvent être accessibles; si des outils de développement (accès admin temporaires) ont été laissés actifs.
Même quand WordPress est “clean”, la configuration web peut laisser des traces d’autres déploiements.
Sécuriser journaux et rotation
Après durcissement, une partie de votre sécurité vient de la détection. Si les logs saturent ou ne sont pas conservés, vous perdez votre capacité à corriger rapidement.
Je vérifie donc:
- rotation des logs; access aux logs pour investiguer; format cohérent des logs pour repérer les anomalies.
Le trade-off: conserver trop longtemps peut coûter en stockage, mais ne pas conserver du tout coûte encore plus cher quand l’enquête commence trop tard.
Deuxième liste courte: points serveur à contrôler juste après durcissement PHP
Je la garde volontairement courte, car vous avez déjà le reste dans l’esprit.
- Contrôler le comportement d’exécution dans uploads (aucune interprétation PHP si non nécessaire). Vérifier les permissions sur wp-content (et sur les dossiers de cache) pour éviter l’écriture excessive. Vérifier la présence de fichiers modifiés récents hors uploads (notamment dans thèmes et plugins). Confirmer la configuration de sécurité web (directions de type “deny by default” sur les répertoires non destinés au public). Vérifier les logs après quelques heures de trafic normal pour détecter des erreurs PHP induites par le durcissement.
Edge cases: quand le durcissement doit composer avec la réalité
Sur des sites “simples”, durcir est relativement direct. Sur des sites “vivants”, vous tombez sur des cas plus délicats.
Uploads avec traitement serveur
Certains sites utilisent des fonctions qui nécessitent une exécution ou un traitement spécifique lors de l’upload. Si votre pipeline d’images ou un plugin d’optimisation s’appuie sur des hooks côté serveur, bloquer trop agressivement peut casser des formats, ou empêcher la génération de variantes (webp, avif, tailles multiples).
Dans ce cas, la règle n’est pas de renoncer, c’est de cibler. Vous pouvez souvent autoriser le traitement via le code WordPress, tout en bloquant l’exécution de fichiers dans des répertoires d’uploads de manière générale.
Plugins qui utilisent des fonctions “limites”
Certains plugins de formulaires, d’import, de syndication, ou de synchronisation externe utilisent des fonctions PHP plus “sensibles”. Si vous désactivez ces fonctions sans tester, vous verrez des erreurs en back-office, et parfois des bugs silencieux côté front.
Ma stratégie ici: tester d’abord en staging, puis en production sur une plage limitée si possible. Si vous n’avez pas de staging, vous testez sur une fonctionnalité critique à la fois.
Hébergements mutualisés
En mutualisé, le contrôle php.ini peut être restreint. Vous pouvez avoir la main sur .htaccess, mais pas sur certaines directives. Dans ce cas, je concentre le durcissement sur les leviers disponibles: règles web, erreurs, restrictions par chemins, et bonnes pratiques de permissions.
Ce n’est pas “moins sécurisé”. C’est simplement adapté.
Après le durcissement: traiter le scan comme un cycle, pas comme un événement
Vous allez faire un scan malware WordPress, nettoyer, puis durcir. Très bien. Mais la durabilité vient du cycle.
- Après une mise à jour WordPress ou plugin, le comportement change. Je revalide les éléments sensibles. Après un incident, je surveille davantage pendant quelques jours. Après un durcissement significatif, je garde un œil sur les logs, pas uniquement sur le chargement des pages.
Un site sécurisé n’est pas un site “figé”. C’est un site qui évolue avec ses garde-fous.
Ce que je recommande pour planifier votre travail
Si vous ne savez pas par où commencer, je recommande de vous poser une question simple: quel chemin l’attaquant a le plus de chances d’emprunter chez vous?
- S’il a déjà eu accès au back-office, la priorité devient l’hygiène PHP et les règles web qui empêchent l’exécution dans les zones d’uploads. S’il a eu un accès via un plugin, la priorité devient l’assainissement de l’environnement d’exécution et la réduction des capacités PHP inutiles. S’il s’est servi d’une configuration déréglée (droits, interprétation de fichiers), la priorité devient la cohérence de permissions et de règles serveur.
Vous gagnerez du temps en alignant vos réglages avec la réalité de votre configuration, plutôt qu’en appliquant une recette générique.
Dernier point: la sécurité, c’est aussi de savoir observer
Le durcissement PHP et serveur, c’est bien. Mais sans observation, vous avancez à l’aveugle. Sur un site WordPress, les journaux sont votre radio. Ils vous disent si une modification a cassé quelque chose, et ils vous disent aussi si des tentatives suspectes continuent.
Gardez une trace de ce que vous changez, même brièvement: quelles directives, quelle date, quel impact observé. Quand vous faites un nouveau scan, vous pouvez comparer. Ça rend la prochaine intervention plus rapide et plus fiable.
Si vous me dites votre configuration exacte (Apache ou Nginx, PHP-FPM ou mod_php, type d’hébergement, et si vous avez la main sur php.ini ou seulement .htaccess), je peux vous proposer un plan de durcissement adapté, avec les contraintes réalistes de votre environnement et les tests de validation à effectuer.
