Sécuriser WordPress n'est pas une case à cocher mais une suite de couches qui se renforcent. Le CMS fait tourner plus de 40 % du web : c'est précisément cette ubiquité qui en fait la première cible des bots d'attaque automatisés. Sur l'infrastructure de notre hébergement web sécurisé, le pare-feu applicatif bloque chaque mois plusieurs millions de requêtes hostiles dirigées contre des sites WordPress — l'écrasante majorité étant du brute force sur /wp-login.php.
Ce guide liste 17 mesures concrètes, classées par couple impact / effort plutôt que par ordre arbitraire. Pour chacune : le vecteur d'attaque réel qu'elle bloque, comment l'appliquer (code prêt à coller quand c'est pertinent), et le faux sentiment de sécurité à éviter. La distinction est explicite entre ce qui relève de vous — mots de passe, mises à jour, 2FA — et ce qui relève de l'hébergeur — WAF, isolation, anti-DDoS, EDR.
À retenir
- Le brute force sur
/wp-login.phpetxmlrpc.phpest le vecteur n°1 observé sur le WAF Tomco — plusieurs millions de requêtes bloquées par mois.- Trois mesures à impact élevé et effort faible couvrent l'essentiel : 2FA, mises à jour, mots de passe uniques.
- La majorité des compromissions exploitent un plugin ou thème obsolète ou piraté (« nulled »), pas une faille du cœur de WordPress.
- Bloquer l'exécution PHP dans
/uploadsneutralise la quasi-totalité des webshells uploadés.- Aucune mesure ne remplace une sauvegarde externalisée et testée : c'est le dernier rempart après compromission.
Sommaire
- Panorama des menaces WordPress en 2026
- Matrice impact / effort des 17 mesures
- Couche accès : login, 2FA et wp-admin
- Couche fichiers : permissions, wp-config et uploads
- Couche applicative : mises à jour, plugins et thèmes
- Couche serveur : WAF, anti-DDoS, EDR et isolation
- Sauvegardes et plan de reprise
- Monitoring et détection des intrusions
- Récapitulatif : sécuriser WordPress par ordre de priorité
- Questions fréquentes
L'essentiel en un coup d'œil
| Question | Réponse courte |
|---|---|
| Vecteur d'attaque n°1 ? | Force brute sur /wp-login.php et xmlrpc.php — plusieurs millions de requêtes bloquées par mois sur le WAF Tomco |
| Les 3 mesures prioritaires ? | 2FA, mises à jour cœur/plugins/thèmes, mots de passe longs et uniques |
| Cause de compromission la plus fréquente ? | Plugin ou thème obsolète ou piraté (« nulled »), pas le cœur de WordPress |
| Ce qui relève de l'hébergeur ? | WAF, anti-DDoS, isolation des environnements, EDR, supervision SOC 24/7 |
| Dernier rempart après compromission ? | Sauvegarde externalisée et testée — chez Tomco, rétention 90 jours + snapshots ZFS |
Panorama des menaces WordPress en 2026
Les attaques contre WordPress sont presque entièrement automatisées. Un bot ne cible personne en particulier : il balaie des plages entières d'adresses IP à la recherche de signatures connues — plugin vulnérable, formulaire /wp-login.php ouvert, fichier xmlrpc.php accessible. La menace est industrielle, opportuniste, indifférente à la taille du site.
Le scénario type se déroule en deux phases. D'abord la reconnaissance : empreinte de la version, énumération des comptes utilisateurs (/?author=1), scan des chemins de plugins connus. Ensuite l'exploitation : force brute sur le login, exploitation d'une vulnérabilité publiée (CVE), ou injection via un point d'entrée mal protégé. Le cœur de WordPress est rarement la porte d'entrée — il est audité et corrigé rapidement. Ce sont les extensions tierces qui concentrent l'essentiel des failles, comme le confirment les bases de référence telles que WPScan et le registre public cve.org.
Top 5 des vecteurs observés sur le WAF Tomco
Le tableau ci-dessous classe les cinq vecteurs les plus fréquents bloqués par le pare-feu Tomco, en ordre de grandeur de volume mensuel sur l'ensemble de l'infrastructure.
| Rang | Vecteur d'attaque | Volume bloqué (ordre de grandeur, par mois) |
|---|---|---|
| 1 | Force brute sur /wp-login.php et xmlrpc.php |
plusieurs millions de requêtes |
| 2 | Scan et exploitation de plugins/thèmes obsolètes (CVE) | centaines de milliers |
| 3 | Amplification de brute force via XML-RPC (system.multicall) |
centaines de milliers |
| 4 | Scan de wp-config.php et fichiers sensibles |
dizaines de milliers |
| 5 | Tentatives d'upload et d'accès à des webshells dans /uploads |
milliers |
Ces ordres de grandeur recoupent la cartographie de l'OWASP Top 10, où le contrôle d'accès défaillant et les composants vulnérables figurent en tête des risques applicatifs. La conséquence pratique : la majorité du budget défensif doit porter sur l'authentification et la mise à jour des composants.
Ce que Tomco gère par défaut
La couche serveur est traitée en amont, indépendamment de la configuration WordPress. L'infrastructure technologie multicouche Tomco inclut par défaut un pare-feu applicatif, une protection anti-DDoS jusqu'à 3 Tbps, un EDR (détection et réponse sur les terminaux), l'isolation des environnements web et une supervision SOC 24/7. Cette base réduit la surface exposée avant tout durcissement applicatif.
Matrice impact / effort des 17 mesures
Toutes les mesures de sécurité n'ont pas le même rapport entre l'effet obtenu et l'effort consenti. Hiérarchiser par ce rapport évite le piège classique : passer des heures sur un réglage marginal pendant que la 2FA n'est toujours pas activée. La matrice ci-dessous classe les 17 mesures du meilleur rapport impact/effort vers le plus coûteux.
Les mesures se répartissent en quatre couches : accès, fichiers, applicatif, serveur. Une couche franchie ne compromet pas le site si les suivantes tiennent — c'est la défense en profondeur.
| # | Mesure | Impact | Effort | Responsable |
|---|---|---|---|---|
| 1 | Activer la 2FA sur tous les comptes admin | Élevé | Faible | Utilisateur |
| 2 | Maintenir cœur, plugins et thèmes à jour | Élevé | Faible | Utilisateur |
| 3 | Mots de passe longs et uniques (gestionnaire) | Élevé | Faible | Utilisateur |
| 4 | Pare-feu applicatif (WAF) devant WordPress | Élevé | Faible (hébergeur) | Hébergeur |
| 5 | Bloquer l'exécution PHP dans /uploads |
Élevé | Faible | Utilisateur |
| 6 | Extensions de réputation, jamais « nulled » | Élevé | Faible | Utilisateur |
| 7 | HTTPS systématique + HSTS | Élevé | Faible | Partagé |
| 8 | Sauvegardes 3-2-1 testées | Élevé | Moyen | Partagé |
| 9 | Isolation des environnements + EDR + SOC | Élevé | Faible (hébergeur) | Hébergeur |
| 10 | Verrouiller l'accès à wp-config.php |
Moyen | Faible | Utilisateur |
| 11 | Désactiver l'éditeur de fichiers de l'admin | Moyen | Faible | Utilisateur |
| 12 | Désactiver ou restreindre XML-RPC | Moyen | Faible | Utilisateur |
| 13 | Limiter les tentatives de connexion | Moyen | Faible | Partagé |
| 14 | Supprimer plugins et thèmes inutilisés | Moyen | Faible | Utilisateur |
| 15 | Protection anti-DDoS réseau | Variable | Faible (hébergeur) | Hébergeur |
| 16 | Corriger les permissions fichiers/dossiers | Moyen | Moyen | Utilisateur |
| 17 | Protéger wp-admin par authentification serveur | Moyen | Moyen | Utilisateur |
Les sections suivantes détaillent ces mesures regroupées par couche, avec pour chacune le vecteur bloqué, la mise en œuvre et le faux sentiment de sécurité à éviter.
Couche accès : login, 2FA et wp-admin
La couche accès regroupe tout ce qui protège l'authentification : le formulaire /wp-login.php, le fichier xmlrpc.php et l'interface /wp-admin. C'est la surface la plus attaquée — à elle seule, la force brute sur ces points d'entrée représente le premier vecteur du WAF Tomco, avec plusieurs millions de requêtes bloquées chaque mois.
Mots de passe longs et uniques
Bloque : la force brute et le credential stuffing (réutilisation d'identifiants issus de fuites massives).
Appliquer : au moins 16 caractères, uniques par site, générés et stockés dans un gestionnaire (Bitwarden, KeePassXC, 1Password). Bannir admin/admin, le nom du domaine, et tout mot de passe déjà utilisé ailleurs.
Faux sentiment de sécurité : forcer un changement de mot de passe tous les 30 jours sans gestionnaire pousse les utilisateurs vers des variantes faibles (Motdepasse1, Motdepasse2). Un mot de passe long, unique et stable, couplé à la 2FA, protège mieux qu'une rotation contrainte.
Authentification à deux facteurs (2FA)
Bloque : la prise de compte même lorsque le mot de passe est connu de l'attaquant (fuite, phishing, keylogger).
Appliquer : un plugin TOTP de réputation comme le plugin officiel Two-Factor ou WP 2FA, sur tous les comptes à rôle élevé (administrateur, éditeur). Une clé matérielle WebAuthn/FIDO2 offre la meilleure protection.
Faux sentiment de sécurité : la 2FA par SMS est vulnérable au détournement de carte SIM (SIM-swapping). Privilégier une application d'authentification ou une clé physique. La 2FA reste une couche : elle ne dispense pas de limiter les tentatives de connexion.
Limiter les tentatives de connexion
Bloque : la force brute par épuisement — le vecteur n°1 observé sur l'infrastructure.
Appliquer : un plafond de tentatives par adresse IP avec temporisation progressive. Côté hébergeur, le pare-feu applique cette limite en amont de PHP, ce qui économise les ressources serveur. La documentation développeur WordPress sur la force brute détaille les approches complémentaires.
Faux sentiment de sécurité : limiter par IP seule ne suffit pas contre un botnet distribué qui répartit l'attaque sur des milliers d'adresses. Cette mesure se combine obligatoirement avec la 2FA et le WAF.
Protéger l'accès à wp-admin
Bloque : l'essentiel du trafic hostile vers la zone d'administration, avant qu'il n'atteigne PHP.
Appliquer : une authentification serveur (.htpasswd) devant wp-login.php, ou une restriction par IP si l'administration se fait depuis une adresse fixe.
# Authentification serveur supplémentaire devant le login WordPress
<Files wp-login.php>
AuthType Basic
AuthName "Acces restreint"
AuthUserFile /home/utilisateur/.htpasswd
Require valid-user
</Files>Faux sentiment de sécurité : renommer la page de connexion (« hide login ») n'est pas une mesure de durcissement mais de discrétion. Les scanners finissent par trouver l'URL ; c'est utile pour réduire le bruit des logs, pas pour bloquer un attaquant déterminé.
Désactiver ou restreindre XML-RPC
Bloque : l'amplification de force brute — la méthode system.multicall teste des centaines d'identifiants en une seule requête — et certains dénis de service par pingback. C'est le troisième vecteur du WAF Tomco.
Appliquer : si aucune application mobile ni Jetpack ni pingback n'en dépend, bloquer le fichier au niveau serveur.
# Blocage complet de XML-RPC si aucun usage légitime
<Files xmlrpc.php>
Require all denied
</Files>Faux sentiment de sécurité : désactiver XML-RPC ne dispense pas de protéger wp-login.php. Les bots attaquent les deux points d'entrée en parallèle ; fermer l'un sans l'autre laisse la porte principale ouverte.
Couche fichiers : permissions, wp-config et uploads
La couche fichiers limite ce qu'un attaquant peut lire, écrire ou exécuter une fois qu'il a obtenu un accès partiel. Elle transforme une intrusion potentiellement totale en incident contenu. Le durcissement du fichier .htaccess en est le pivot technique de cette couche.
Corriger les permissions
Bloque : la lecture ou l'écriture non autorisée si un processus est compromis, et l'escalade de privilèges entre fichiers.
Appliquer : 755 pour les dossiers, 644 pour les fichiers, et plus restrictif encore pour wp-config.php.
# Permissions standard recommandées par WordPress
find /chemin/du/site -type d -exec chmod 755 {} \;
find /chemin/du/site -type f -exec chmod 644 {} \;
# wp-config.php : lecture limitée au propriétaire et au groupe
chmod 640 wp-config.phpFaux sentiment de sécurité : appliquer 777 « pour que ça marche » ouvre l'écriture à tout le monde et constitue l'une des erreurs les plus exploitées. À l'inverse, des permissions parfaites ne protègent pas d'un plugin vulnérable exécuté par le serveur lui-même.
Verrouiller wp-config.php
Bloque : la lecture des identifiants de base de données et des clés de salage via un accès direct ou un scan — le quatrième vecteur du WAF Tomco, avec des dizaines de milliers de tentatives mensuelles.
Appliquer : interdire l'accès HTTP au fichier, idéalement le déplacer hors de la racine web.
# Interdire tout accès direct à wp-config.php
<Files wp-config.php>
Require all denied
</Files>Faux sentiment de sécurité : bloquer l'accès HTTP ne protège pas si un autre site du même compte est compromis et lit le fichier sur le disque — d'où l'importance de l'isolation des environnements (couche serveur).
Désactiver l'éditeur de fichiers de l'admin
Bloque : la modification directe du code via le tableau de bord si un compte administrateur est pris — un attaquant ne peut plus injecter de backdoor depuis l'interface.
Appliquer : une seule ligne dans wp-config.php.
// Interdire l'édition de thèmes/plugins depuis l'admin
define('DISALLOW_FILE_EDIT', true);Faux sentiment de sécurité : cette directive n'empêche pas l'upload de fichiers via FTP ou via un plugin compromis. C'est une couche de plus, pas une barrière unique.
Bloquer l'exécution PHP dans /uploads
Bloque : l'exécution des webshells uploadés — le payload final de nombreuses compromissions. Le répertoire /uploads ne doit jamais exécuter de PHP.
Appliquer : un .htaccess dédié dans wp-content/uploads.
# wp-content/uploads/.htaccess — interdire l'exécution de scripts
<FilesMatch "\.(?i:php|phtml|php3|php4|php5|php7|phps)$">
Require all denied
</FilesMatch>Faux sentiment de sécurité : cette règle bloque l'exécution mais pas l'upload lui-même. Elle se combine avec un WAF capable de détecter le pattern d'upload malveillant en amont.
Couche applicative : mises à jour, plugins et thèmes
La couche applicative est celle où se jouent la majorité des compromissions réelles. Le cœur de WordPress est rarement en cause : ce sont les extensions tierces, obsolètes ou piratées, qui ouvrent la porte. Maintenir cette couche propre est l'effort le plus rentable après l'authentification.
Maintenir le cœur, les plugins et les thèmes à jour
Bloque : l'exploitation des vulnérabilités publiées (CVE) — le deuxième vecteur du WAF Tomco, avec des centaines de milliers de scans de plugins obsolètes par mois.
Appliquer : activer les mises à jour mineures automatiques du cœur, automatiser les plugins critiques, et suivre les divulgations via WPScan ou le registre CVE.
// Mises à jour mineures du cœur en automatique (déjà par défaut)
define('WP_AUTO_UPDATE_CORE', 'minor');Faux sentiment de sécurité : « je mettrai à jour quand j'aurai le temps » est la posture la plus risquée. Le délai entre la publication d'une CVE et son exploitation de masse se compte en heures. Un site à jour ferme la fenêtre avant que les bots ne l'ouvrent.
Supprimer ce qui ne sert pas
Bloque : la surface d'attaque dormante. Un plugin désactivé reste sur le disque et peut être exploité directement par son URL, même inactif.
Appliquer : supprimer (et non seulement désactiver) les plugins et thèmes inutilisés, y compris les thèmes par défaut non utilisés. Garder l'inventaire minimal.
Faux sentiment de sécurité : désactiver n'est pas supprimer. Le code reste accessible et vulnérable tant qu'il n'est pas effacé du serveur.
N'installer que des extensions de réputation
Bloque : les backdoors préinstallées. Les versions « nulled » (extensions premium piratées) contiennent fréquemment du code malveillant injecté.
Appliquer : installer exclusivement depuis le répertoire officiel WordPress.org ou directement chez l'éditeur, en suivant les recommandations officielles de durcissement WordPress. Vérifier la date de dernière mise à jour, le nombre d'installations actives et la réactivité du support.
Faux sentiment de sécurité : « c'est le même plugin que la version payante » est faux. La version nulled est modifiée — elle reste l'une des causes les plus directes de compromission de sites WordPress.
Couche serveur : WAF, anti-DDoS, EDR et isolation
La couche serveur regroupe ce que l'administrateur d'un site ne peut pas mettre en place seul : elle relève de l'hébergeur. C'est la première ligne de défense, en amont de WordPress, et le principal critère de différenciation entre offres d'hébergement — un angle détaillé dans notre comparatif sécurité des hébergeurs.
Le pare-feu applicatif (WAF)
Bloque : les requêtes hostiles avant qu'elles n'atteignent PHP — force brute, injections, scans de chemins, patterns d'upload malveillant. Un WAF (Web Application Firewall) inspecte le trafic HTTP et applique des règles de filtrage.
Appliquer : sur l'infrastructure Tomco, le WAF applicatif est inclus par défaut et s'appuie sur ModSecurity. Voici un exemple de règle chaînée qui bloque l'amplification de brute force via XML-RPC.
# Exemple ModSecurity : blocage de system.multicall (amplification de brute force)
SecRule REQUEST_FILENAME "@endsWith /xmlrpc.php" \
"id:1005010,phase:2,deny,status:403,t:none,chain,\
msg:'XML-RPC system.multicall amplification blocked'"
SecRule REQUEST_BODY "@contains system.multicall" "t:none"Faux sentiment de sécurité : un WAF n'est pas un antivirus. Il filtre le trafic entrant mais ne nettoie pas un site déjà infecté. Mal réglé, il génère aussi des faux positifs qui cassent des fonctionnalités légitimes — d'où l'intérêt d'un WAF maintenu par l'hébergeur.
La protection anti-DDoS
Bloque : la saturation réseau ou applicative destinée à rendre le site indisponible.
Appliquer : la protection anti-DDoS se joue au niveau réseau, en amont. Tomco filtre jusqu'à 3 Tbps. Côté site, un cache serveur efficace absorbe les pics applicatifs — un point traité dans le guide optimiser les performances de WordPress.
Faux sentiment de sécurité : aucun plugin WordPress ne peut arrêter un déni de service volumétrique. Quand l'attaque sature le lien réseau, PHP n'est même plus sollicité. La défense se situe nécessairement en amont, chez l'hébergeur.
HTTPS systématique et HSTS
Bloque : l'interception et l'altération des données en transit (attaque de l'homme du milieu), ainsi que le vol de cookies de session.
Appliquer : un certificat SSL (Let's Encrypt suffit), une redirection 301 systématique vers HTTPS, et l'en-tête HSTS pour forcer le navigateur à n'utiliser que le canal chiffré.
Faux sentiment de sécurité : HTTPS chiffre le transport, il ne sécurise pas le site lui-même. Un site entièrement compromis peut parfaitement être servi en HTTPS — le cadenas vert ne dit rien de l'intégrité du code.
Isolation des environnements et EDR
Bloque : la propagation latérale entre sites et l'exécution de code malveillant détectée comportementalement.
Appliquer : relève de l'hébergeur. Tomco isole les environnements web, déploie un EDR et assure une supervision SOC 24/7. L'architecture de sécurité multicouche garantit qu'un site compromis ne contamine pas ses voisins.
Faux sentiment de sécurité : sur un hébergement mutualisé sans isolation, un seul site compromis peut en contaminer des dizaines d'autres sur le même serveur. L'isolation des environnements est un critère de choix d'hébergeur à part entière, pas une option.
Sauvegardes et plan de reprise
La sauvegarde n'empêche pas la compromission : elle garantit la reprise. C'est le dernier rempart quand toutes les couches précédentes ont été franchies. La référence est la règle 3-2-1, que toute stratégie de sauvegarde 3-2-1 décline ainsi : trois copies des données, sur deux supports différents, dont une hors site.
La rétention compte autant que la fréquence. Une backdoor peut rester dormante plusieurs semaines avant activation : si la rétention ne couvre que sept jours, toutes les sauvegardes disponibles contiennent déjà l'infection. L'infrastructure Tomco conserve 90 jours de sauvegardes via Enhance, complétés par des snapshots ZFS au niveau du système de fichiers. Cette profondeur permet de remonter à un état antérieur à une compromission découverte tardivement — un avantage décisif pour récupérer un site WordPress piraté sans repartir de zéro.
Une sauvegarde jamais restaurée n'est pas une garantie, c'est une hypothèse. Tester la restauration sur un environnement de préproduction, au moins une fois par trimestre, valide que les copies sont exploitables et que le délai de reprise est connu à l'avance.
Monitoring et détection des intrusions
Détecter une intrusion tôt limite son impact. Le monitoring couvre trois dimensions complémentaires, à mettre en place avant l'incident — pas pendant.
Les logs d'accès révèlent les signaux faibles : pics de requêtes sur /wp-login.php, vague de 404 sur des chemins de plugins (signature d'un scan), trafic sortant anormal. Les surveiller permet d'agir avant l'exploitation.
L'intégrité des fichiers (File Integrity Monitoring) détecte toute modification d'un fichier du cœur. Un fichier core altéré est un signal fort : le cœur de WordPress ne se modifie jamais en dehors d'une mise à jour. Sur l'infrastructure Tomco, l'EDR analyse en continu et la supervision SOC 24/7 traite les alertes critiques.
Les alertes doivent porter sur les événements à fort signal : création d'un nouveau compte administrateur, modification d'un fichier du cœur, pic de trafic inhabituel. La défaillance de journalisation et de supervision figure explicitement dans l'OWASP Top 10 comme un risque majeur.
Avant l'incident, le plan de réponse doit être écrit : qui isole le site, où sont les sauvegardes saines, comment basculer en maintenance. Savoir précisément comment récupérer un site WordPress piraté fait la différence entre un incident d'une heure et une indisponibilité de plusieurs jours.
Récapitulatif : sécuriser WordPress par ordre de priorité
La checklist ci-dessous reprend les 17 mesures par horizon d'action, du plus immédiat au plus structurel.
Cette semaine — impact élevé, effort faible (couche utilisateur)
- Activer la 2FA sur tous les comptes administrateur.
- Vérifier que le cœur, les plugins et les thèmes sont à jour ; activer les mises à jour automatiques.
- Remplacer les mots de passe faibles par des mots de passe longs et uniques via gestionnaire.
- Supprimer tous les plugins et thèmes inutilisés.
- Vérifier que HTTPS est forcé et HSTS actif.
Ce mois-ci — durcissement des fichiers (couche utilisateur)
- Bloquer l'exécution PHP dans
/uploads. - Verrouiller l'accès à
wp-config.php. - Ajouter
DISALLOW_FILE_EDITdanswp-config.php. - Corriger les permissions fichiers (
644) et dossiers (755). - Désactiver ou restreindre XML-RPC.
- Limiter les tentatives de connexion et, si possible, protéger
wp-adminpar authentification serveur.
Structurel — le choix de l'hébergeur (couche serveur)
- WAF applicatif, anti-DDoS, isolation des environnements, EDR et supervision SOC.
- Sauvegardes externalisées à rétention longue, testées régulièrement.
Cette couche serveur ne se bricole pas : elle se choisit. Sur l'hébergement web Tomco, elle est incluse par défaut, ce qui laisse à l'administrateur la couche applicative à durcir. La sécurité WordPress est un empilement : aucune mesure n'est suffisante seule, mais ensemble elles rendent l'attaque non rentable pour un bot, qui passera à la cible suivante.