La plupart des compromissions de sites WordPress ne commencent pas par une faille zero-day exotique. Le plus souvent, la cause est ordinaire : une extension abandonn\u00e9e, un mot de passe r\u00e9utilis\u00e9, un compte d\u2019h\u00e9bergement expos\u00e9, des autorisations excessives ou une sauvegarde qui n\u2019a jamais \u00e9t\u00e9 test\u00e9e.<\/p>\n
Cette checklist de s\u00e9curit\u00e9 WordPress<\/strong> est ax\u00e9e sur la pr\u00e9vention. Elle explique comment r\u00e9duire le risque de compromission, limiter les d\u00e9g\u00e2ts caus\u00e9s par un compte d\u00e9rob\u00e9 et conserver une capacit\u00e9 de r\u00e9cup\u00e9ration en cas de d\u00e9faillance des contr\u00f4les. Si le site redirige d\u00e9j\u00e0 les visiteurs, envoie des e-mails suspects, affiche des comptes administrateur inconnus ou d\u00e9clenche des avertissements du navigateur ou des moteurs de recherche, consid\u00e9rez cela comme un incident actif, et non comme une maintenance courante. Pr\u00e9servez les preuves et enqu\u00eatez sur la cause avant de tenter un nettoyage.<\/p>\n Vous ne pouvez pas s\u00e9curiser un site WordPress si personne n\u2019a une vision fiable de ce qui fonctionne, des personnes ayant acc\u00e8s et de l\u2019emplacement des identifiants critiques. Un inventaire r\u00e9v\u00e8le souvent les v\u00e9ritables risques : une copie de pr\u00e9production oubli\u00e9e, une extension install\u00e9e pour une campagne ponctuelle, un ancien compte de prestataire ou un compte de bureau d\u2019enregistrement de domaine contr\u00f4l\u00e9 par un seul employ\u00e9.<\/p>\n Consignez les \u00e9l\u00e9ments suivants avant de modifier les param\u00e8tres :<\/p>\n Supprimez les extensions et th\u00e8mes inactifs qui ne sont plus n\u00e9cessaires. Du code inactif reste du code sur le serveur : il peut contenir une vuln\u00e9rabilit\u00e9, \u00eatre r\u00e9activ\u00e9 par accident ou compliquer l\u2019enqu\u00eate lors d\u2019un incident. Conserver un th\u00e8me WordPress par d\u00e9faut r\u00e9cent comme solution de secours est raisonnable ; conserver des ann\u00e9es d\u2019anciens th\u00e8mes commerciaux ne l\u2019est g\u00e9n\u00e9ralement pas.<\/p>\n Les mises \u00e0 jour comptent parmi les contr\u00f4les de s\u00e9curit\u00e9 WordPress les plus utiles. Mais \u00ab tout mettre \u00e0 jour imm\u00e9diatement en production \u00bb n\u2019est pas une politique. Sur un site comportant des mod\u00e8les personnalis\u00e9s, des extensions WooCommerce, de la mise en cache ou des int\u00e9grations externes, une mise \u00e0 jour non test\u00e9e peut cr\u00e9er un autre type d\u2019incident.<\/p>\n Un processus de mise \u00e0 jour pratique se pr\u00e9sente ainsi :<\/p>\n Les versions mineures de WordPress sont g\u00e9n\u00e9ralement destin\u00e9es \u00e0 \u00eatre appliqu\u00e9es rapidement, en particulier lorsqu\u2019elles contiennent des correctifs de s\u00e9curit\u00e9. Les versions majeures de WordPress, les mises \u00e0 jour d\u2019extensions et les mises \u00e0 niveau de PHP m\u00e9ritent des tests de compatibilit\u00e9 sur les sites complexes. La cadence exacte d\u00e9pend du site, mais laisser des mises \u00e0 jour connues sans y toucher pendant des mois est rarement une d\u00e9cision commerciale d\u00e9fendable.<\/p>\n Examinez la prise en charge de PHP dans le cadre du m\u00eame processus. WordPress peut encore fonctionner sur une ancienne version de PHP, mais cela ne signifie pas que cette version est prise en charge par les mainteneurs de PHP ou votre h\u00e9bergeur. Planifiez les mises \u00e0 niveau de PHP comme des op\u00e9rations de maintenance test\u00e9es plut\u00f4t que d\u2019attendre une modification impos\u00e9e par l\u2019h\u00e9bergeur.<\/p>\n Le contr\u00f4le des acc\u00e8s est plus important que de masquer l\u2019URL de connexion ou d\u2019installer plusieurs extensions de s\u00e9curit\u00e9 qui se chevauchent. D\u00e8s lors qu\u2019un attaquant poss\u00e8de un mot de passe administrateur valide \u2014 ou un acc\u00e8s au compte e-mail utilis\u00e9 pour r\u00e9initialiser les mots de passe \u2014 de nombreuses mesures de durcissement cosm\u00e9tiques offrent peu de protection.<\/p>\n Chaque personne doit disposer d\u2019un compte WordPress individuel. Les comptes administrateur partag\u00e9s compliquent inutilement la suppression des acc\u00e8s, la tra\u00e7abilit\u00e9 et l\u2019enqu\u00eate sur les incidents. Attribuez le r\u00f4le le moins \u00e9lev\u00e9 permettant \u00e0 chacun d\u2019effectuer son travail :<\/p>\n Examinez les comptes administrateur au moins chaque trimestre et imm\u00e9diatement apr\u00e8s des changements de personnel, d\u2019agence ou de fournisseur. Un compte administrateur inconnu est un signal d\u2019incident, et non un \u00e9l\u00e9ment \u00e0 reporter au prochain examen.<\/p>\n Utilisez des mots de passe longs et uniques, stock\u00e9s dans un gestionnaire de mots de passe r\u00e9put\u00e9. Ne r\u00e9utilisez pas les identifiants WordPress pour l\u2019h\u00e9bergement, le bureau d\u2019enregistrement de domaine, le DNS, la messagerie ou d\u2019autres services. La messagerie m\u00e9rite une attention particuli\u00e8re, car le contr\u00f4le d\u2019une bo\u00eete e-mail de r\u00e9initialisation de mot de passe peut conduire au contr\u00f4le du site web.<\/p>\n Activez l\u2019authentification multifacteur pour les administrateurs WordPress ainsi que pour les comptes d\u2019h\u00e9bergement, de domaine, de DNS et de messagerie partout o\u00f9 le prestataire la prend en charge. Examinez les codes de r\u00e9cup\u00e9ration, les adresses e-mail de r\u00e9cup\u00e9ration et les appareils enregistr\u00e9s dans le cadre de la suppression des acc\u00e8s. Une authentification multifacteur li\u00e9e au t\u00e9l\u00e9phone d\u2019un ancien employ\u00e9 ou \u00e0 une bo\u00eete aux lettres non surveill\u00e9e ne constitue pas un contr\u00f4le complet.<\/p>\n D\u00e9sactivez les comptes qui ne sont plus n\u00e9cessaires. Pr\u00e9f\u00e9rez les cl\u00e9s SSH \u00e0 l\u2019acc\u00e8s SSH par mot de passe. Utilisez des comptes distincts lorsque la plateforme d\u2019h\u00e9bergement le permet et \u00e9vitez d\u2019accorder par d\u00e9faut un acc\u00e8s illimit\u00e9 \u00e0 la production \u00e0 tous les d\u00e9veloppeurs. Les identifiants de base de donn\u00e9es, secrets de d\u00e9ploiement et cl\u00e9s API ne doivent pas \u00eatre valid\u00e9s dans des d\u00e9p\u00f4ts publics ni envoy\u00e9s par e-mail ordinaire.<\/p>\n Le durcissement rend les chemins d\u2019attaque courants moins exploitables. La mise en \u0153uvre d\u00e9pend de l\u2019h\u00e9bergeur et du mod\u00e8le de d\u00e9ploiement ; testez donc les modifications de configuration en pr\u00e9production et conservez une possibilit\u00e9 de retour en arri\u00e8re.<\/p>\n Par d\u00e9faut, les administrateurs WordPress peuvent modifier les fichiers des th\u00e8mes et extensions depuis le tableau de bord. Sur un site de production, cette commodit\u00e9 est un risque : un compte administrateur compromis peut servir \u00e0 modifier directement le code PHP.<\/p>\n Ajoutez cette ligne dans Cela d\u00e9sactive les \u00e9diteurs de fichiers des th\u00e8mes et extensions dans le tableau de bord WordPress. Cela n\u2019emp\u00eache pas les mises \u00e0 jour normales et ne remplace pas la s\u00e9curit\u00e9 du serveur. Effectuez les modifications de code l\u00e9gitimes via un processus de d\u00e9ploiement contr\u00f4l\u00e9, SFTP ou SSH.<\/p>\n Prot\u00e9gez L\u2019objectif est simple : WordPress et le processus de d\u00e9ploiement pr\u00e9vu doivent pouvoir lire ou modifier les fichiers dont ils ont besoin, tandis que les utilisateurs et processus non concern\u00e9s ne le peuvent pas. Ne rendez pas les fichiers ou r\u00e9pertoires accessibles en \u00e9criture \u00e0 tous simplement pour r\u00e9soudre une erreur de mise \u00e0 jour. Cela masque g\u00e9n\u00e9ralement un probl\u00e8me de d\u00e9ploiement ou de propri\u00e9t\u00e9 tout en \u00e9largissant la surface d\u2019attaque.<\/p>\n Pour les sites de production g\u00e9r\u00e9s, envisagez un flux de travail dans lequel l\u2019installation d\u2019extensions et de th\u00e8mes s\u2019effectue uniquement via un processus de mise en production approuv\u00e9. Cette approche ne convient pas \u00e0 toutes les \u00e9quipes \u00e9ditoriales, mais elle est utile lorsque les d\u00e9veloppeurs g\u00e8rent les d\u00e9ploiements et que les utilisateurs de contenu ne doivent pas pouvoir introduire de nouveau code ex\u00e9cutable.<\/p>\n La r\u00e8gle op\u00e9rationnelle importe davantage qu\u2019un param\u00e8tre unique : d\u00e9cidez qui peut ajouter, mettre \u00e0 jour et supprimer du code en production, puis clarifiez explicitement cette responsabilit\u00e9.<\/p>\n Les tentatives de connexion automatis\u00e9es sont courantes sur les sites WordPress publics. La r\u00e9ponse utile consiste en des contr\u00f4les superpos\u00e9s, pas en du th\u00e9\u00e2tre s\u00e9curitaire.<\/p>\n Modifier l\u2019URL de connexion peut r\u00e9duire le bruit automatis\u00e9 de faible qualit\u00e9, mais ce n\u2019est pas une fronti\u00e8re de s\u00e9curit\u00e9 principale. Cela ne doit jamais remplacer l\u2019authentification multifacteur, une bonne hygi\u00e8ne des mots de passe, le contr\u00f4le des r\u00f4les et la limitation de d\u00e9bit.<\/p>\n Une sauvegarde n\u2019est utile que si elle est compl\u00e8te, isol\u00e9e de l\u2019environnement compromis et restaurable. Une sauvegarde de la seule base de donn\u00e9es peut omettre les t\u00e9l\u00e9versements et le code personnalis\u00e9. Une sauvegarde conserv\u00e9e uniquement dans le m\u00eame compte d\u2019h\u00e9bergement peut \u00eatre indisponible lorsque le compte est compromis. Une sauvegarde qui n\u2019a jamais \u00e9t\u00e9 restaur\u00e9e est une hypoth\u00e8se, pas un plan de r\u00e9cup\u00e9ration.<\/p>\n Conservez des sauvegardes de la base de donn\u00e9es et des fichiers, stockez au moins une copie s\u00e9par\u00e9ment du compte d\u2019h\u00e9bergement de production et d\u00e9finissez la conservation selon les exigences de l\u2019entreprise. Un site e-commerce traitant des commandes quotidiennement a une tol\u00e9rance \u00e0 la perte de donn\u00e9es tr\u00e8s diff\u00e9rente de celle d\u2019un site vitrine mis \u00e0 jour une fois par mois.<\/p>\n Testez la restauration dans un environnement non public. Confirmez que le site restaur\u00e9 se charge, que les m\u00e9dias sont pr\u00e9sents, que les donn\u00e9es attendues existent et que les fonctions critiques telles que les formulaires ou la commande fonctionnent. Le stockage des sauvegardes requiert la m\u00eame discipline d\u2019acc\u00e8s que la production : utilisateurs nomm\u00e9s, identifiants uniques et authentification multifacteur lorsqu\u2019elle est disponible.<\/p>\n Pour les sites plus importants, d\u00e9finissez deux objectifs :<\/p>\n Il s\u2019agit de d\u00e9cisions commerciales, pas d\u2019\u00e9tiquettes techniques. Elles d\u00e9terminent la fr\u00e9quence des sauvegardes, la conservation, l\u2019architecture d\u2019h\u00e9bergement et le niveau de pr\u00e9paration \u00e0 la r\u00e9cup\u00e9ration n\u00e9cessaire.<\/p>\n L\u2019analyse des logiciels malveillants est utile, mais une analyse propre ne prouve pas qu\u2019un site est s\u00e9curis\u00e9. La d\u00e9tection d\u00e9pend de ce que l\u2019outil reconna\u00eet, de ce qu\u2019il peut inspecter et du comportement de la compromission. De nouveaux comptes administrateur, des enregistrements DNS modifi\u00e9s, des t\u00e2ches planifi\u00e9es inattendues, des fichiers alt\u00e9r\u00e9s et des e-mails sortants inhabituels peuvent \u00eatre des signaux tout aussi importants.<\/p>\n \u00c9tablissez une routine de surveillance autour des \u00e9l\u00e9ments suivants :<\/p>\n Choisissez les outils en fonction de l\u2019environnement plut\u00f4t que d\u2019installer plusieurs extensions qui analysent toutes les fichiers, ex\u00e9cutent des pare-feux et envoient des alertes. Votre h\u00e9bergeur, CDN, prestataire de surveillance et outils WordPress existants couvrent peut-\u00eatre d\u00e9j\u00e0 une partie de la pile. Des contr\u00f4les dupliqu\u00e9s peuvent consommer des ressources, cr\u00e9er des param\u00e8tres contradictoires et laisser sans responsable clairement d\u00e9sign\u00e9 pour r\u00e9pondre aux alertes.<\/p>\n La s\u00e9curit\u00e9 WordPress ne se limite pas au tableau de bord. Un point de terminaison REST personnalis\u00e9, un gestionnaire de formulaires, un webhook, une int\u00e9gration de paiement ou une extension sur mesure peut introduire plus de risques que l\u2019installation WordPress standard.<\/p>\n Examinez les fonctionnalit\u00e9s personnalis\u00e9es apr\u00e8s des changements significatifs et avant de connecter des syst\u00e8mes sensibles. Portez une attention particuli\u00e8re aux v\u00e9rifications d\u2019autorisation, \u00e0 la validation des entr\u00e9es, \u00e0 l\u2019\u00e9chappement des sorties, \u00e0 l\u2019utilisation des nonces pour les actions administratives, au traitement des t\u00e9l\u00e9versements de fichiers, au stockage des cl\u00e9s API et aux messages d\u2019erreur r\u00e9v\u00e9lant des d\u00e9tails internes.<\/p>\n Pour un site comportant des extensions personnalis\u00e9es ou des int\u00e9grations critiques pour l\u2019activit\u00e9, un audit de s\u00e9curit\u00e9 du code WordPress<\/a> cibl\u00e9 fournit des r\u00e9ponses qu\u2019une checklist de configuration ne peut pas apporter. Une checklist r\u00e9duit les lacunes op\u00e9rationnelles courantes ; une revue de code examine la logique applicative, les autorisations et les fronti\u00e8res de confiance.<\/p>\nCommencez par un inventaire pr\u00e9cis<\/h2>\n
\n
1. \u00c9tablissez une politique de mise \u00e0 jour qui ne provoque pas d\u2019interruptions<\/h2>\n
\n
2. R\u00e9duisez les acc\u00e8s avant d\u2019ajouter des outils de s\u00e9curit\u00e9<\/h2>\n
Utilisez des comptes individuels et le principe du moindre privil\u00e8ge<\/h3>\n
\n
Exigez des mots de passe uniques et l\u2019authentification multifacteur<\/h3>\n
Prot\u00e9gez l\u2019acc\u00e8s au serveur et au d\u00e9ploiement<\/h3>\n
3. Durcissez la configuration WordPress et les autorisations de fichiers<\/h2>\n
D\u00e9sactivez l\u2019\u00e9diteur de fichiers du tableau de bord en production<\/h3>\n
wp-config.php<\/code>, au-dessus de la ligne indiquant \u00ab That\u2019s all, stop editing \u00bb :<\/p>\ndefine( 'DISALLOW_FILE_EDIT', true );<\/code><\/pre>\nUtilisez les autorisations pour appliquer la propri\u00e9t\u00e9, pas pour contourner les erreurs<\/h3>\n
wp-config.php<\/code> avec des param\u00e8tres de propri\u00e9t\u00e9 et d\u2019autorisations adapt\u00e9s \u00e0 la configuration de votre serveur. Lorsque l\u2019h\u00e9bergeur le permet, conservez la configuration sensible en dehors de la racine publique des documents. Ne copiez pas aveugl\u00e9ment des valeurs d\u2019autorisation depuis un tutoriel : Apache, PHP-FPM, les conteneurs et les plateformes WordPress g\u00e9r\u00e9es peuvent avoir des exigences diff\u00e9rentes.<\/p>\nContr\u00f4lez qui peut introduire du code ex\u00e9cutable<\/h3>\n
4. Prot\u00e9gez les points d\u2019entr\u00e9e de connexion et de l\u2019application<\/h2>\n
\n
5. Consid\u00e9rez les sauvegardes comme un contr\u00f4le de r\u00e9cup\u00e9ration<\/h2>\n
\n
6. Surveillez les changements significatifs, pas seulement les logiciels malveillants<\/h2>\n
\n
7. Incluez le code personnalis\u00e9 et les int\u00e9grations dans l\u2019examen de s\u00e9curit\u00e9<\/h2>\n