Sécuriser un site WordPress : la liste de vérification complète

WordPress propulse une part considérable des sites web dans le monde. Cette popularité en fait une cible rentable pour les robots qui balayent Internet à la recherche de versions obsolètes, d'extensions vulnérables ou de mots de passe faibles. La plupart des attaques ne visent pas votre site en particulier : elles visent toute installation qui présente une faille connue.

Le cœur de WordPress est audité et corrigé rapidement. Les compromissions proviennent en très grande majorité de l'écosystème d'extensions et de thèmes, des identifiants compromis et de configurations d'hébergement négligées. La bonne nouvelle est que ces vecteurs se traitent avec des mesures simples, à condition de les appliquer systématiquement.

Cette liste est organisée par ordre d'impact. Les premières sections bloquent les attaques les plus courantes ; les dernières renforcent la défense en profondeur et la capacité à réagir si un incident survient malgré tout. Aucune mesure ne remplace les autres.

Les mises à jour sont la mesure de sécurité la plus efficace et la moins coûteuse. Une vulnérabilité publiée dans une extension est exploitée par des robots dans les heures ou les jours qui suivent. Un site qui n'est pas mis à jour reste exposé indéfiniment, quelle que soit la qualité du reste de sa configuration.

Activez les mises à jour automatiques pour les correctifs mineurs du cœur, et planifiez une revue régulière des extensions et thèmes, idéalement sur un environnement de préproduction pour détecter les régressions avant la mise en ligne. Supprimez tout ce qui n'est pas utilisé : une extension désactivée mais présente reste un point d'entrée potentiel.

Vérifiez également la version de PHP. Chaque branche de PHP n'est maintenue en sécurité que pendant une durée limitée ; une version en fin de vie ne reçoit plus de correctifs. Votre hébergeur doit vous permettre de rester sur une branche supportée, et le changement doit être testé.

Les attaques par force brute et par réutilisation de mots de passe divulgués restent extrêmement répandues. Chaque compte administrateur doit avoir un mot de passe long et unique, géré par un gestionnaire de mots de passe, et l'authentification à deux facteurs doit être imposée à tous les rôles ayant des droits d'administration.

Appliquez le principe du moindre privilège : les rédacteurs n'ont pas besoin du rôle administrateur. Supprimez le compte « admin » par défaut s'il existe encore, et passez en revue périodiquement la liste des utilisateurs pour retirer les comptes inactifs, notamment ceux des anciens prestataires.

Limitez le nombre de tentatives de connexion et, si vous n'utilisez pas d'application mobile ni d'outil de publication à distance, désactivez l'interface XML-RPC, qui permet des attaques d'authentification amplifiées. L'API REST peut également être restreinte pour les utilisateurs non authentifiés selon vos besoins.

Plusieurs réglages réduisent la surface d'attaque sans affecter le fonctionnement du site. Désactivez l'éditeur de fichiers intégré au tableau de bord avec la constante DISALLOW_FILE_EDIT : un attaquant qui obtient un accès administrateur ne pourra pas injecter directement du code PHP depuis l'interface.

Vérifiez les permissions des fichiers et des dossiers : le serveur web ne doit pas pouvoir écrire dans les fichiers PHP du cœur, et le fichier wp-config.php doit être protégé en lecture. Empêchez l'exécution de scripts PHP dans le dossier des téléversements, où sont souvent déposées les portes dérobées.

Côté hébergement, exigez HTTPS partout avec un certificat valide et renouvelé automatiquement, isolez chaque site dans son propre espace, sans partage d'utilisateur système entre plusieurs sites, et ajoutez les en-têtes de sécurité HTTP : Content-Security-Policy, X-Content-Type-Options, Referrer-Policy et Strict-Transport-Security.

Un pare-feu applicatif (WAF) filtre les requêtes malveillantes avant qu'elles n'atteignent PHP : injections SQL, tentatives d'inclusion de fichiers, exploitation de failles connues. Il peut être fourni par un service en amont, comme un CDN avec WAF, ou par une extension de sécurité côté serveur. Le WAF en amont protège aussi contre les attaques volumétriques.

La surveillance complète la prévention. Un contrôle d'intégrité des fichiers vous alerte si un fichier du cœur ou d'une extension est modifié en dehors d'une mise à jour. Un journal des connexions et des actions d'administration permet d'identifier rapidement l'origine d'un incident et son étendue.

Configurez également des alertes de disponibilité et surveillez les listes noires des navigateurs et des moteurs de recherche : un site compromis est souvent signalé par Google avant que son propriétaire ne s'en aperçoive, avec un effet immédiat sur le trafic.

Aucune mesure préventive n'est infaillible. La sauvegarde est ce qui transforme un piratage en incident de quelques heures plutôt qu'en catastrophe. Elle doit couvrir les fichiers et la base de données, être automatique, quotidienne au minimum, et stockée hors du serveur du site.

Testez la restauration régulièrement : une sauvegarde qui n'a jamais été restaurée n'est qu'une hypothèse. Conservez plusieurs versions dans le temps, car une compromission peut être découverte plusieurs semaines après l'intrusion, et la dernière sauvegarde peut déjà contenir la porte dérobée.

Documentez la procédure de reprise : qui intervient, comment restaurer, comment changer tous les identifiants (WordPress, base de données, FTP, hébergeur, clés de sel) et comment vérifier que le site est réellement sain avant de le remettre en ligne.

Si vous constatez des redirections, du contenu inconnu, des alertes de navigateur ou des utilisateurs administrateurs inconnus, mettez le site en maintenance, changez immédiatement tous les mots de passe et conservez une copie de l'état compromis pour analyse. Ne nettoyez pas à l'aveugle.

Le nettoyage consiste à réinstaller le cœur et les extensions depuis des sources officielles, à examiner les fichiers modifiés récemment, la base de données et les tâches planifiées, puis à identifier le vecteur d'entrée pour le corriger. Sans cette dernière étape, le site sera réinfecté.