Sur un petit site WordPress, la sécurité n’est pas un projet : c’est un socle que l’on pose une fois, correctement, et qui n’exige plus d’attention. Trois briques, une demi-journée de mise en place, et la quasi-totalité des attaques automatisées cesse de produire le moindre effet. Voici ce socle, dans l’ordre de déploiement.
Pourquoi un socle minimal plutôt qu’une forteresse
L’essentiel de ce qui frappe un petit WordPress relève du bruit automatisé : robots qui sollicitent wp-login.php, scans de vulnérabilités connues, tentatives d’énumération d’utilisateurs via l’API REST. Aucune de ces attaques ne vise un site en particulier — elles ratissent l’ensemble du web. Le socle décrit ci-dessous coupe cette masse. Le reste — attaque ciblée, faille inédite sur une extension précise — ne se traite pas en trois lignes de configuration, et ne concerne pratiquement jamais un site vitrine.
Le meilleur durcissement n’est pas celui qui bloque tout : c’est celui qui sera encore en place et à jour six mois plus tard.
Brique 1 — Wordfence, la couche applicative
Wordfence protège plus de cinq millions de sites et sa version gratuite couvre l’essentiel : pare-feu applicatif, scanner de logiciels malveillants comparant les fichiers du cœur à ceux du dépôt officiel, limitation de débit, protection contre les attaques par force brute et double authentification.
Réglages minimaux après installation :
- Basculer le pare-feu en mode Extended Protection, qui s’exécute avant PHP et non comme une simple extension.
- Activer la double authentification sur tous les comptes administrateur.
- Activer le blocage de l’énumération des utilisateurs et masquer la version de WordPress.
- Réduire les alertes par courriel aux seules alertes critiques : une notification systématique finit par n’être plus lue.
Brique 2 — Fail2ban, la couche réseau
Wordfence agit au niveau de PHP. Fail2ban agit en amont, au niveau du serveur : il lit les journaux Nginx et bannit l’adresse IP au niveau du pare-feu système dès qu’un motif d’attaque se répète. L’attaquant cesse alors de consommer des ressources PHP.
# /etc/fail2ban/filter.d/wp-login.conf
[Definition]
failregex = ^<HOST> -.*"POST /wp-login.php
^<HOST> -.*"POST /xmlrpc.php
ignoreregex =# /etc/fail2ban/jail.d/wordpress.conf
[wp-login]
enabled = true
filter = wp-login
logpath = /home/*/logs/nginx/access.log
port = http,https
maxretry = 3
findtime = 3600
bantime = 3600CF-Connecting-IP via le module RealIP) doit être vérifiée avant d’armer la règle.Le filtre se teste systématiquement avant activation :
fail2ban-regex /home/monsite/logs/nginx/access.log \
/etc/fail2ban/filter.d/wp-login.confBrique 3 — Mots de passe d’application
Les mots de passe d’application, natifs dans WordPress, permettent de donner à un script, une intégration ou une routine automatisée un identifiant révocable, distinct du mot de passe principal du compte. Chaque intégration obtient le sien ; sa révocation n’affecte aucune autre.
Deux règles d’exploitation en découlent : ne jamais réutiliser un mot de passe d’application entre deux intégrations, et vérifier qu’aucune extension de sécurité ne les désactive globalement — Wordfence propose ce réglage, dont l’activation coupe silencieusement toutes les intégrations REST du site.
Compléments à coût nul
| Mesure | Effet |
|---|---|
En-têtes de sécurité (X-Content-Type-Options, Referrer-Policy, Permissions-Policy) | Réduction de la surface d’attaque côté navigateur |
| Désactivation de l’édition de fichiers dans l’administration | Empêche la modification de code depuis un compte compromis |
| Comptes administrateur nominatifs, aucun compte « admin » | Supprime la cible par défaut des attaques par force brute |
| Sauvegardes chiffrées hors du serveur de production | Seule mesure qui répare réellement après incident |
Ce qu’il faut retenir
Trois briques suffisent à traiter la quasi-totalité du risque réel d’un petit site : une couche applicative, une couche réseau et des identifiants révocables pour les intégrations. Tout dispositif supplémentaire doit se juger à une seule aune — sera-t-il encore maintenu dans six mois ?
C’est le socle que je déploie sur la trentaine de sites que j’auto-héberge, derrière CloudPanel et Cloudflare. L’incident qui m’a le plus coûté n’était d’ailleurs pas une intrusion : c’est le réglage Wordfence qui désactive les mots de passe d’application et qui avait coupé toutes mes routines REST, sans alerte. — Simon Janvier
