Un site WordPress n’est jamais plus solide que son extension, son compte ou sa sauvegarde le plus faible. Le cœur de WordPress reçoit régulièrement des mises à jour de sécurité ; ce que vous y ajoutez et la façon dont vous l’exploitez relèvent de votre responsabilité. Cette liste de contrôle couvre les mesures les plus importantes, à peu près dans l’ordre où nous les appliquerions.
1. Tenir à jour le cœur, les extensions et les thèmes
Les mises à jour automatiques en arrière-plan du cœur existent depuis WordPress 3.7 et couvrent par défaut les versions mineures. Depuis WordPress 5.5, vous pouvez aussi activer les mises à jour automatiques de chaque extension et de chaque thème depuis l’interface d’administration.
- Activez les mises à jour automatiques pour les extensions de développeurs réputés, et passez les autres en revue chaque semaine.
- Les mises à jour automatiques reposent sur WP-Cron. Vérifiez les erreurs dans Outils > Santé du site, car si le cron ne fonctionne pas, les mises à jour s’arrêtent sans bruit.
- Assurez-vous de pouvoir revenir en arrière avant de compter sur les mises à jour automatiques. La documentation de WordPress recommande la même chose.
2. Supprimer les extensions abandonnées et inutilisées
Le guide de durcissement de WordPress est sans détour : tenez vos extensions à jour et supprimez celles que vous n’utilisez pas. Les désactiver ne suffit pas, car le code reste sur le serveur.
Le répertoire des extensions de WordPress.org vous donne deux signaux d’alerte :
- Un avertissement jaune indiquant qu’une extension « n’a pas été testée avec les 3 dernières versions majeures de WordPress ».
- Un avertissement rouge indiquant qu’une extension a été fermée et n’est plus disponible au téléchargement. Au bout de 60 jours, la raison est affichée, et « problème de sécurité » fait partie des raisons possibles.
Une extension fermée ne recevra plus de mises à jour via WordPress.org. Remplacez-la. N’installez jamais de copies « nulled » (piratées) d’extensions premium, et n’installez que depuis WordPress.org ou des éditeurs de confiance.
3. Passer en revue les comptes administrateur
Listez tous les comptes dotés du rôle Administrateur et supprimez ceux que personne ne sait justifier. Avec WP-CLI :
wp user list --role=administrator --fields=ID,user_login,user_email,user_registeredDonnez à chaque personne son propre compte nominatif, jamais un identifiant admin partagé. Attribuez le rôle le plus faible qui permet de faire le travail : la plupart des rédacteurs de contenu n’ont pas besoin du rôle Administrateur. Exigez des mots de passe robustes et uniques, idéalement stockés dans un gestionnaire de mots de passe.
4. Activer l’authentification à deux facteurs
Activez la 2FA pour chaque administrateur. Le cœur de WordPress n’inclut pas de 2FA : il vous faut une extension ou un fournisseur d’authentification unique (SSO) qui l’impose. Privilégiez des méthodes comme les clés de sécurité ou les clés d’accès (passkeys) lorsque votre extension les prend en charge, et conservez les codes de récupération en lieu sûr.
5. Limiter les tentatives de connexion et trancher sur XML-RPC
La documentation de WordPress présente wp-login.php et xmlrpc.php comme des cibles courantes d’attaques par force brute. Elle recommande de limiter le nombre de tentatives de connexion en périphérie (un WAF ou un CDN) ou au niveau du serveur web. Une extension de sécurité peut aussi limiter les connexions, mais elle s’exécute en PHP : l’option au niveau du serveur résiste donc mieux à un trafic important.
Si vous n’utilisez pas XML-RPC, désactivez-le. Certaines applications mobiles et certains services comme Jetpack en ont besoin : vérifiez d’abord. Notez que le filtre xmlrpc_enabled ne désactive que les méthodes qui nécessitent une authentification. Les pingbacks et les autres méthodes non authentifiées continuent de fonctionner. Pour le désactiver complètement, bloquez le fichier au niveau du serveur web. Pour nginx :
location = /xmlrpc.php {
deny all;
}6. Désactiver l’éditeur de fichiers intégré
L’éditeur de thèmes et d’extensions du tableau de bord permet à quiconque dispose d’une session administrateur de modifier du code PHP. Désactivez-le dans wp-config.php :
define( 'DISALLOW_FILE_EDIT', true );D’après la documentation de wp-config.php, DISALLOW_FILE_MODS va plus loin et bloque aussi l’installation et la mise à jour des extensions et des thèmes depuis le tableau de bord. Ne l’utilisez que si vous déployez les modifications autrement, par exemple via Git ou WP-CLI.
7. Stocker les sauvegardes hors du serveur et hors de la racine web
Le guide de durcissement recommande des sauvegardes régulières des fichiers et de la base de données, plusieurs instantanés et un emplacement de stockage de confiance. Protégez leur intégrité par le chiffrement, des empreintes enregistrées ou des supports en lecture seule.
Deux règles pratiques en découlent. Une sauvegarde placée dans la racine web, comme un fichier zip dans wp-content, peut être téléchargée par quiconque devine son nom. Une sauvegarde sur le même serveur peut être supprimée par le même attaquant. Gardez au moins une copie à un endroit que les identifiants du site ne permettent pas d’atteindre, et testez une restauration complète.
8. Vérifier l’intégrité des fichiers
WP-CLI peut comparer vos fichiers aux sommes de contrôle officielles de WordPress.org sans charger WordPress :
wp core verify-checksums --include-root
wp plugin verify-checksums --allLa première commande signale les fichiers du cœur modifiés, et --include-root alerte sur les fichiers inattendus dans le répertoire racine. La seconde compare les extensions aux sommes de contrôle de WordPress.org : elle n’est donc utile que pour les extensions qui y sont hébergées. Recherchez aussi les fichiers PHP dans wp-content/uploads, qui ne devrait normalement contenir que des médias.
9. Utiliser un utilisateur de base de données à privilèges minimaux
Donnez à chaque site sa propre base de données et son propre utilisateur de base de données, avec des droits sur cette seule base. Ne vous connectez jamais avec l’utilisateur root de la base de données.
Le guide de durcissement relève que le fonctionnement courant ne nécessite que SELECT, INSERT, UPDATE et DELETE. Il ne recommande pas de retirer DROP, ALTER et GRANT, car les extensions et les mises à jour majeures peuvent avoir besoin de modifier le schéma. Si vous les retirez malgré tout, gardez des sauvegardes testées.
10. Définir les permissions des fichiers
Le point de départ du guide est 755 pour les répertoires et 644 pour les fichiers. Les fichiers du cœur, wp-admin et wp-includes ne doivent être modifiables que par votre compte utilisateur, pas par le serveur web. wp-content fait exception : le serveur web doit pouvoir y écrire pour les téléversements. Pour wp-config.php, le guide suggère 400 ou 440.
find /var/www/example -type d -exec chmod 755 {} \;
find /var/www/example -type f -exec chmod 644 {} \;
chmod 440 /var/www/example/wp-config.phpAdaptez les chemins et les propriétaires à votre hébergement avant d’exécuter ces commandes.
11. Envoyer des en-têtes de sécurité
Des en-têtes comme Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options et Referrer-Policy ajoutent une protection côté navigateur. Définissez-les si possible au niveau du serveur web ou du CDN plutôt que par une extension. Commencez par une Content Security Policy en mode report-only, car les thèmes et les constructeurs de pages peuvent s’appuyer sur des scripts en ligne.
12. Placer un WAF en frontal
La documentation de WordPress décrit trois niveaux : les extensions de sécurité qui filtrent les requêtes au sein de WordPress, un pare-feu au niveau du serveur comme ModSecurity, et les services de proxy inverse qui filtrent le trafic avant qu’il n’atteigne votre serveur. Plus le filtrage a lieu loin du site, moins la charge atteint PHP. Un WAF ne remplace pas les mises à jour. Il vous fait gagner du temps entre la divulgation d’une faille et votre correctif.
En résumé
| Domaine | Minimum |
|---|---|
| Mises à jour | Mises à jour automatiques mineures du cœur activées, extensions revues chaque semaine |
| Extensions | Aucune extension fermée, abandonnée ou inutilisée installée |
| Comptes | Comptes nominatifs, peu d’administrateurs, 2FA pour tous |
| Connexion | Limitation des tentatives au niveau du serveur ou en périphérie, XML-RPC bloqué s’il n’est pas utilisé |
| Modifications du code | DISALLOW_FILE_EDIT défini |
| Sauvegardes | Hors serveur, hors racine web, restauration testée |
| Intégrité | Sommes de contrôle vérifiées, aucun PHP dans uploads |
| Base de données | Un utilisateur par site, avec des droits sur sa seule base |
| Navigateur | HSTS et une CSP testée |
| Périmètre | WAF ou proxy inverse en frontal |
Par où commencer
Commencez par les quatre premiers points. Ils prennent peu de temps et ne nécessitent aucun changement d’hébergement. Vérifiez ensuite vos en-têtes actuels avec notre analyseur d’en-têtes de sécurité.
Si vous souhaitez que ces vérifications soient faites pour vous, SecAudit analyse WordPress à la recherche de logiciels malveillants et de webshells, vérifie l’intégrité des fichiers par rapport aux sommes de contrôle officielles et rapproche les extensions installées des vulnérabilités connues.
