Guides des plugins

Checklist de durcissement de la sécurité WordPress : 12 étapes classées par données d’attaque réelles

2 octobre 2026 · Patrick Schlesinger

Cette checklist de durcissement de la sécurité WordPress compte douze étapes, et leur ordre vient de ce qui a réellement frappé les sites WordPress du réseau ReportedIP entre le 4 juillet et le 1er octobre 2026 : 36 548 événements d’attaque venus de 18 378 adresses. Les scanners à la recherche de fichiers de configuration, de plugins et de numéros de version ont représenté plus de la moitié du total, la devinette de mots de passe est arrivée en deuxième position, et les exploits dont tout le monde parle n’ont été que quelques centaines d’événements en fin de liste.

Chaque étape nomme ce qu’elle ferme, ce qu’elle peut casser et où se trouve l’interrupteur dans ReportedIP Hive. Le cœur de détection et de verrouillage du plugin est gratuit ; les étapes qui demandent le plan Professional le précisent. L’interface du plugin est en anglais, les libellés sont cités tels quels. Vous n’avez pas besoin d’être développeur pour l’essentiel : huit des douze étapes sont des interrupteurs dans un seul plugin gratuit, et le plugin vous montre lesquels sont encore éteints.

Si vous n’avez que dix minutes : la version courte

La version courte prend une dizaine de minutes et couvre les étapes qui arrêtent l’essentiel du trafic du tableau ci-dessous.

1. Téléchargez ReportedIP Hive et installez-le comme n’importe quelle extension : Extensions, Ajouter, Téléverser une extension, choisissez le fichier zip, Activer.
2. Lancez le Quickstart que le plugin ouvre après l’activation. Choisissez le mode, collez votre clé si vous en avez une, activez la protection. Capteurs, pare-feu et blocage progressif sont préréglés pour votre plan.
3. Ouvrez le tableau de bord et parcourez le Hardening Score. Chaque élément qui affiche encore Enable renvoie à son interrupteur. Le second facteur pour votre propre compte est le premier à prendre.

Ce qui a attaqué les sites WordPress ces 90 derniers jours

Les chiffres ci-dessous sont les événements d’attaque que des sites et serveurs WordPress ont signalés au réseau ReportedIP par son API pendant ces 90 jours, comptés par catégorie. Le trafic des honeypots est exclu, et un événement portant plusieurs catégories est compté une fois dans chacune d’elles. L’étape de la checklist qui ferme chaque vecteur figure dans la dernière colonne.

Type d’attaque	Événements	Adresses	Fermé par l’étape
Recherche de fichiers de configuration et de sauvegardes	16 548	7 549	2 et 3
Scan des plugins	16 308	7 515	1 et 3
Scan des versions	16 184	7 480	3
Force brute sur la connexion	11 235	8 010	4, 5 et 8
Énumération des utilisateurs	6 130	3 026	6
Faux robots de moteurs de recherche	1 978	382	11
Force brute par XML-RPC	681	237	7
Tentatives d’exploitation de plugins	574	149	1 et 11
Abus de l’API REST	357	128	7

Deux conclusions découlent du tableau. L’essentiel du trafic est de la reconnaissance : un site qui ne révèle rien reçoit moins d’attaques de suite. Et le petit nombre de tentatives d’exploitation est la seule ligne qui se termine par une compromission, ce qui explique pourquoi les mises à jour restent en tête alors que les lignes de scan sont près de trente fois plus grandes.

La checklist de durcissement en un coup d’œil

Étape	Effort	Peut casser	Dans ReportedIP Hive
1. Mettre à jour et supprimer des plugins	Récurrent	Un thème ou un plugin après une mise à jour majeure	Pas une tâche du plugin
2. Verrouiller les fichiers	Une fois	Les plugins qui écrivent dans leur propre dossier	Block PHP execution in uploads
3. Masquer les empreintes de version	Une fois	Rien	Hide software fingerprints
4. Durcir la connexion	Une fois	Les adresses partagées d’un bureau	Blocage progressif, politique de mots de passe
5. Imposer le second facteur	Une fois par rôle	Les utilisateurs sans téléphone	Two-Factor Authentication
6. Stopper l’énumération des utilisateurs	Une fois	Les pages d’auteur publiques	Défense contre l’énumération
7. Fermer XML-RPC et REST	Une fois	Jetpack, l’application mobile, les configurations headless	Access Lockdown
8. Masquer la page de connexion	Une fois	Les favoris de vos rédacteurs	Hide Login
9. Envoyer des en-têtes de sécurité	Une fois	Les intégrations et une CSP stricte	Security Headers
10. HTTPS, PHP et proxys	Une fois	Les vieux plugins sur un PHP récent	Sources de proxy de confiance
11. Placer un pare-feu devant	Une fois	Les formulaires qui envoient du code	Web Application Firewall
12. Sauvegardes et surveillance	Récurrent	Rien	System Status

1. Mettre à jour le cœur, les plugins et les thèmes, et supprimer ce que vous n’utilisez pas

Le scan des plugins était la deuxième ligne du tableau pour une raison : un scanner qui sait quels plugins et quelles versions un site fait tourner peut les comparer aux vulnérabilités publiées et revenir avec le seul exploit qui convient. Les 574 tentatives d’exploitation sont la fin de cette chaîne. Une installation dont les plugins sont à jour n’offre rien où la chaîne puisse aboutir.

• Activez les mises à jour automatiques du cœur de WordPress, au moins pour les versions mineures, qui portent les correctifs de sécurité.
• Mettez à jour les plugins et les thèmes selon un calendrier, chaque semaine pour la plupart des sites, le jour même pour un plugin dont la vulnérabilité est publiée.
• Supprimez les plugins et les thèmes inactifs. Un plugin inactif a toujours ses fichiers sur le disque, et un scanner lit des fichiers, pas un état d’activation.
• Testez les grosses mises à jour sur une copie de préproduction avant qu’elles n’atteignent le site en ligne, en particulier WooCommerce et les constructeurs de pages.

Si personne dans l’entreprise ne porte ce calendrier, confiez-le à quelqu’un qui le fait chaque semaine. La maintenance WordPress de CMS ADMINS, l’équipe munichoise derrière ReportedIP, applique les mises à jour à un rythme fixe, avec un environnement de préproduction dans les offres supérieures, réalise des sauvegardes quotidiennes, surveille le site en continu et héberge sur des serveurs allemands pour les clients qui veulent maintenance et hébergement auprès d’un seul interlocuteur.

2. Verrouiller wp-config.php, les permissions de fichiers et l’éditeur de fichiers

La plus grande ligne du tableau, 16 548 événements, ce sont des scanners qui demandent des copies de sauvegarde et des fichiers de configuration qui ne devraient jamais être lisibles de l’extérieur. Trois réglages ferment l’essentiel de cette surface.

Ajoutez ces deux lignes à wp-config.php au-dessus de la ligne qui indique que l’édition s’arrête là. La première retire l’éditeur de thèmes et de plugins de wp-admin, de sorte qu’une session d’administrateur volée ne peut pas coller du PHP dans votre thème. La seconde arrête l’installateur de plugins et de thèmes, que vous ne voulez que sur un site où chaque changement passe de toute façon par un déploiement.

define( 'DISALLOW_FILE_EDIT', true );
define( 'DISALLOW_FILE_MODS', true ); // seulement si vous déployez les plugins vous-même

Appliquez les permissions de fichiers que recommande le guide de durcissement WordPress : répertoires en 755, fichiers en 644, et wp-config.php en 600 pour que seul l’utilisateur du serveur web puisse le lire. Ne laissez jamais une copie nommée wp-config.php.bak ou wp-config.old à côté ; un serveur web la sert en texte clair, et c’est exactement ce que demandaient les 16 548 requêtes.

find /chemin/du/site -type d -exec chmod 755 {} \;
find /chemin/du/site -type f -exec chmod 644 {} \;
chmod 600 /chemin/du/site/wp-config.php

Le dossier des téléversements est le seul endroit où un visiteur peut déposer un fichier sur votre serveur. Hive ajoute une règle qui refuse d’y exécuter du PHP, de sorte qu’un script arrivé par un formulaire de téléversement défaillant ne peut pas être lancé. Sur Apache, le plugin écrit lui-même la règle dans le .htaccess des téléversements ; sur nginx, il affiche un extrait à coller. L’interrupteur s’appelle Block PHP execution in uploads sous Protection, Firewall & Bots, Access Lockdown.

Si modifier des fichiers sur le serveur n’est pas votre domaine, prenez seulement le dernier interrupteur et demandez à votre hébergeur les deux lignes et les permissions. Pour un hébergeur, c’est l’affaire de cinq minutes.

3. Cesser de livrer vos numéros de version aux scanners

WordPress écrit sa version dans le code source des pages, dans les flux et dans les URL des scripts et des styles, et 16 184 événements en 90 jours étaient des scanners qui lisaient précisément cela. Retirer les empreintes ne corrige rien en soi. Cela cesse de donner au scanner la liste de ce qu’il doit essayer ensuite, et c’est pourquoi cette étape vient si tôt pour le peu de travail qu’elle demande.

Dans Hive, l’interrupteur s’appelle Hide software fingerprints, dans la même section Access Lockdown. Deux autres dispositifs attrapent les scanners à l’entrée : le détecteur de scan compte les chemins manqués par adresse et bloque après une rafale, et les chemins leurres répondent à une requête vers un fichier qui n’existe sur aucun vrai site par un blocage et un signalement au réseau. Les deux sont gratuits et actifs par défaut ; le guide des chemins leurres explique ce qu’ils font et ne font pas.

4. Rendre la connexion coûteuse : noms uniques, mots de passe forts, blocages progressifs

La force brute sur la connexion a représenté 11 235 événements venus de 8 010 adresses, la dispersion la plus large de toutes les lignes : la plupart de ces adresses ont essayé quelques fois puis sont passées à autre chose. Ce schéma décide de la défense. Bloquer par adresse seule ne tient pas face à 8 010 adresses, donc le mot de passe doit être impossible à deviner et les tentatives doivent coûter quelque chose à l’attaquant.

• Aucun compte nommé admin. Créez un nouvel administrateur avec un nom que personne ne peut deviner, connectez-vous avec lui, supprimez l’ancien et attribuez son contenu au nouveau compte.
• Des mots de passe forts et uniques, avec une vérification des fuites. La politique de mots de passe de Hive fixe une longueur minimale et des classes de caractères et peut comparer un nouveau mot de passe aux fuites connues sans envoyer le mot de passe nulle part.
• Un blocage progressif plutôt qu’un bannissement fixe. Hive compte les échecs de connexion par adresse et bloque pour quelques minutes à la première infraction et pour des jours en cas de récidive, de sorte qu’un collègue qui fait une faute de frappe n’est pas exclu pour une journée. Le guide du blocage par force brute détaille l’échelle.
• Partagez ce que vous apprenez. En mode Community Network, une adresse déjà signalée par d’autres sites est refusée avant même la vérification du mot de passe, et vos propres blocages aident le site suivant.

5. Imposer l’authentification à deux facteurs à chaque rôle qui peut éditer

Un second facteur est la seule étape qui rend un mot de passe volé ou deviné sans valeur, et c’est pour cela qu’il est l’élément le plus lourd du score de durcissement. Hive livre quatre méthodes : une application d’authentification, les passkeys et les clés matérielles, un code par e-mail, et le SMS sur le plan Professional via le relais géré. Les trois premières sont gratuites dans tous les plans, y compris le mode Local Shield entièrement hors ligne.

L’imposer à un rôle est ce qui compte. Sous Protection, Core protection, Two-Factor Authentication, choisissez les rôles qui doivent utiliser un second facteur, au minimum les administrateurs et les rédacteurs. Les utilisateurs ont un délai de grâce pour le configurer, les codes de récupération couvrent la perte d’un téléphone, et le parcours de réinitialisation du mot de passe demande lui aussi le second facteur, de sorte qu’une boîte mail volée ne peut pas le contourner. Le guide de l’authentification à deux facteurs compare les quatre méthodes.

Professional ajoute l’escalade adaptative : une connexion depuis un nouveau pays, un nouveau réseau ou un nouvel appareil redemande le second facteur, même sur un appareil de confiance. Pour une boutique, la variante vitrine affiche le défi dans le thème WooCommerce, sur Mon compte et au passage en caisse.

6. Stopper l’énumération des utilisateurs

Avant de deviner des mots de passe, un robot veut des noms d’utilisateur, et WordPress les distribue à quatre endroits : la redirection ?author=1, le point de terminaison des utilisateurs de l’API REST, la réponse oEmbed et le message d’erreur de connexion qui dit si c’est le nom ou le mot de passe qui était faux. Les 6 130 événements d’énumération sont des robots qui collectent des noms pour les 11 235 tentatives de connexion ci-dessus.

La défense contre l’énumération de Hive ferme les quatre d’un coup et compte les sondes par adresse, de sorte qu’un robot qui insiste est bloqué. Les sites qui pointent vers leurs pages d’auteur peuvent les laisser publiques ; les trois autres restent fermées. L’interrupteur est actif par défaut sous Protection, Core protection.

7. Fermer XML-RPC, l’API REST et les autres portes que vous n’utilisez pas

La force brute par XML-RPC et l’abus de l’API REST ont totalisé environ mille événements, bien moins que la page de connexion, et ce sont les deux interrupteurs les plus susceptibles de casser quelque chose. Testez donc avant de vous y fier. XML-RPC est nécessaire à l’application Jetpack, à l’application mobile WordPress et à quelques outils de publication ; l’API REST est utilisée par l’éditeur de blocs, la plupart des plugins de formulaires et de boutique et tout front-end headless.

L’Access Lockdown de Hive propose les interrupteurs avec le juste milieu intégré. Disable XML-RPC éteint complètement le point de terminaison et les pingbacks ; si vous en avez besoin, un second interrupteur retire seulement la méthode multicall qui empile des centaines de tentatives de mot de passe dans une seule requête. REST API access peut rester ouvert, se limiter aux utilisateurs connectés ou se restreindre à des rôles choisis, avec une liste d’espaces de noms qui restent toujours joignables pour une bannière de cookies ou un plugin de boutique. Disable RSS and Atom feeds s’adresse aux sites auxquels personne n’est abonné.

Chaque interrupteur est gratuit, éteint par défaut et réversible depuis le même écran. La liste complète figure dans la documentation Access Lockdown.

8. Masquer la page de connexion et fermer wp-admin aux visiteurs

Déplacer la page de connexion hors de wp-login.php n’arrête pas un attaquant ciblé, mais cela retire le site de chaque balayage automatisé qui essaie l’adresse par défaut, et c’est là que commence l’essentiel de la devinette de mots de passe. Le Hide Login de Hive définit un slug personnalisé, décide de ce que répond l’ancienne adresse et journalise ce qui la demande encore. Close wp-admin for visitors renvoie les visiteurs non connectés loin de la zone d’administration au lieu de leur montrer le formulaire.

Communiquez la nouvelle adresse à vos rédacteurs avant de basculer, et gardez à l’esprit la liste blanche du plugin pour le réseau du bureau : une adresse qui y figure n’est jamais bloquée, quoi qu’elle fasse.

9. Envoyer des en-têtes de sécurité

Les en-têtes de réponse disent au navigateur ce qu’il doit refuser : deviner un type de fichier, encadrer vos pages sur un site étranger, divulguer l’adresse complète quand un visiteur suit un lien, ou retomber en HTTP. Les trois de base, X-Content-Type-Options, X-Frame-Options et Referrer-Policy, sont gratuits dans Hive et sûrs sur presque tous les sites. HSTS, Permissions-Policy, une Content-Security-Policy qui démarre en mode rapport seul et le trio cross-origin viennent avec Professional.

Deux mises en garde tirées de l’écran de réglages lui-même : n’activez jamais HSTS avant que HTTPS fonctionne partout, car les navigateurs s’en souviennent pendant la durée que vous fixez, et faites toujours tourner une Content-Security-Policy en mode rapport seul d’abord, car une politique appliquée trop stricte fait paraître une page cassée. Les en-têtes que votre serveur envoie déjà sont détectés et laissés tels quels. Vérifiez le résultat de l’extérieur avec le Security Header Check.

Si rien de tout cela ne vous parle : activez les trois en-têtes de base et laissez le reste éteint. Cela seul dépasse déjà ce que la plupart des sites envoient.

10. HTTPS, une version de PHP à jour et la vraie adresse du client

Trois choses relèvent de la couche d’hébergement et aucun plugin ne peut les faire à votre place. HTTPS avec un certificat valide sur chaque sous-domaine, parce que chaque étape ci-dessus suppose que le cookie de session voyage chiffré. Une version de PHP qui reçoit encore des correctifs de sécurité, parce qu’un PHP non maintenu est une vulnérabilité sans correctif à venir. Et, derrière Cloudflare ou tout proxy inverse, l’en-tête qui transporte la vraie adresse du visiteur.

Le dernier point décide si toutes les autres étapes fonctionnent. Si le plugin voit l’adresse du proxy au lieu de celle du visiteur, il bloque le proxy et laisse passer l’attaquant. Le réglage de proxy de confiance de Hive prend l’en-tête et les plages du proxy ; la page System Status avertit quand un en-tête est défini sans plages. Si vous préférez ne pas porter du tout la couche d’hébergement, les offres de maintenance de CMS ADMINS incluent l’hébergement sur des serveurs allemands avec une version de PHP maintenue à jour.

11. Placer un pare-feu devant PHP, et le laisser se resserrer sous attaque

Les 574 tentatives d’exploitation et les 1 978 faux robots de moteurs de recherche sont la raison d’être d’un pare-feu applicatif. Le pare-feu de Hive inspecte chaque requête à la recherche d’injection SQL, de cross-site scripting, de traversée de chemins, d’injection de commandes et d’outillage de scan, et le moteur avec son jeu de règles de base OWASP est gratuit dans tous les plans. Un drop-in optionnel bloque avant même le chargement de WordPress, avec la configuration Apache et nginx générée pour vous. La détection des robots vérifiés confirme Googlebot et Bingbot par leurs plages d’adresses officielles et signale ou bloque les imposteurs.

Professional ajoute deux choses. Les jeux de règles plus profonds arrivent signés via Priority Sync au fil de leur publication, et le Hardening Mode réagit à une attaque coordonnée : quand de nombreuses adresses frappent la connexion dans un court laps de temps, le plugin resserre ses seuils sur tout le site pendant une heure, puis les relâche. La force brute distribuée d’un botnet s’arrête en plein vol au lieu de passer sous la limite par adresse. Le guide du pare-feu et le guide du Hardening Mode couvrent les deux en détail.

12. Des sauvegardes que vous avez restaurées, une surveillance et un contrôle de disponibilité

Une sauvegarde ne compte qu’une fois que vous l’avez restaurée. Gardez des copies quotidiennes hors du serveur web, conservez-les assez longtemps pour remonter avant une compromission remarquée tard, et restaurez-en une sur un site de préproduction au moins une fois par trimestre pour que la procédure soit connue avant d’être nécessaire.

La surveillance est l’autre moitié. La page System Status de Hive liste ce qui échoue d’habitude en silence : un cron à l’arrêt, un en-tête de proxy de confiance sans plages, un envoi de mails en échec, un administrateur sans second facteur. Chaque constat porte une gravité, l’heure de sa première apparition et un lien vers le réglage concerné. Sur le plan Business, le journal d’audit enregistre qui a changé quel réglage, plugin, fichier ou compte, avec l’ancienne et la nouvelle valeur, ce dont vous avez besoin le lendemain d’un incident.

Mesurer le résultat : le score de durcissement

Chaque étape de cette checklist que le plugin peut voir est notée sur le tableau de bord de Hive. Le score de durcissement pondère treize éléments, du second facteur imposé aux empreintes masquées, attribue une note de A+ à F et relie chaque élément à son réglage. Une installation fraîche avec les valeurs par défaut démarre bas, à dessein : le score mesure ce que vous avez activé, pas ce que le plugin pourrait faire.

Les deux boutons sous les jauges ouvrent Mozilla Observatory et securityheaders.com, pour que vous puissiez confirmer la partie en-têtes du score avec un outil qui n’est pas le nôtre. La construction du score est décrite dans la documentation du score.

Quelles étapes demandent Hive Professional

L’essentiel de cette checklist tourne sur le plugin gratuit. Professional, 14,90 euros par mois TTC pour trois domaines, ajoute les éléments qui demandent une infrastructure gérée ou un flux de règles.

Élément de la checklist	Free	Professional
Seize capteurs et blocage progressif	Oui	Oui
Interrupteurs Access Lockdown et Hide Login	Oui	Oui
Second facteur par application, passkey et e-mail	Oui	Oui
Second facteur par SMS	Non	Oui
Escalade adaptative par rôle	Non	Oui
En-têtes de sécurité de base	Oui	Oui
HSTS, Permissions-Policy, CSP, en-têtes cross-origin	Non	Oui
Moteur de pare-feu et base OWASP	Oui	Oui
Jeux de règles plus profonds via Priority Sync	Non	Oui
Hardening Mode lors d’attaques coordonnées	Non	Oui
Score de durcissement et System Status	Oui	Oui

Questions sur le durcissement de WordPress

Un plugin de sécurité suffit-il à durcir WordPress ?

Un plugin de sécurité couvre huit des douze étapes de cette liste : la connexion, le second facteur, l’énumération, les interrupteurs de verrouillage, la page de connexion masquée, les en-têtes, le pare-feu et le score. Les mises à jour, les permissions de fichiers, HTTPS et les sauvegardes vivent hors du plugin, sur le serveur et dans une routine, et aucun plugin ne peut les prendre en charge.

Désactiver XML-RPC casse-t-il Jetpack ou l’application WordPress ?

Oui, les deux utilisent XML-RPC et cessent de fonctionner quand le point de terminaison est éteint. Le second interrupteur de Hive garde XML-RPC en marche et retire seulement la méthode multicall qui empile des centaines de tentatives de mot de passe dans une seule requête, c’est-à-dire la partie que les attaquants utilisent.

À quelle fréquence faut-il reprendre la checklist ?

L’étape 1 se fait chaque semaine et l’étape 12 chaque trimestre. Les dix autres se règlent une fois et restent réglées ; le score de durcissement du tableau de bord montre d’un coup d’œil quand l’une d’elles a été désactivée, par exemple après un conflit de plugins.

Ai-je encore besoin d’un plugin pare-feu derrière Cloudflare ?

Cloudflare filtre en bordure et ne voit jamais un échec de connexion WordPress, un commentaire ou l’envoi d’un formulaire, et c’est là que se produisent la plupart des événements du tableau ci-dessus. Les deux couches se complètent, à condition de dire au plugin de faire confiance à l’en-tête Cloudflare pour l’adresse du visiteur.

Pour aller plus loin

• Guide de démarrage Hive
• Registre de disponibilité système
• Protection contre le spam de formulaires
• Obtenir ReportedIP Hive