Sécurité WordPress pour agences : audit et durcissement complet

Sécurité WordPress pour agences : audit et durcissement complet

En 2025, le registre Patchstack a recensé 11 334 nouvelles vulnérabilités dans l'écosystème WordPress — soit 42 % de plus qu'en 2024. Parmi elles, 46 % n'avaient aucun correctif disponible au moment de leur divulgation publique. Autrement dit, mettre ses plugins à jour ne suffit plus : il faut aussi configurer le serveur pour absorber les failles que les développeurs n'ont pas encore corrigées.

Ce guide donne la checklist d'audit en 20 points que nous appliquons aux parcs WordPress, puis la configuration Nginx de durcissement complète — copiable et commentée ligne à ligne — que les autres guides ne fournissent pas.

• État de la menace WordPress en 2025-2026
• Audit de sécurité en 20 points
• Durcissement Nginx : configuration complète
• Plugins de sécurité : lequel choisir
• Intégrer l'audit dans la maintenance mensuelle
• Cas pratique : site infecté par un backdoor

État de la menace WordPress en 2025-2026

WordPress fait tourner 41,5 % des sites web mondiaux. Cette part de marché en fait la cible privilégiée des scanners automatisés : dès qu'une CVE est publiée pour un plugin populaire, les exploitations massives démarrent en médiane au bout de 5 heures. La moitié des vulnérabilités à fort impact sont exploitées dans les 24 heures suivant leur divulgation.

La répartition des 11 334 vulnérabilités recensées en 2025 est sans ambiguïté :

• 91 % dans les extensions (plugins)
• 9 % dans les thèmes
• 6 vulnérabilités uniquement dans le cœur WordPress, toutes jugées à faible risque

Le chiffre qui change la stratégie : les défenses des hébergeurs classiques ne bloquent que 26 % des tentatives d'exploitation, et seulement 12 % des attaques spécifiques à WordPress. La configuration serveur et le durcissement applicatif constituent donc la ligne de défense réelle — pas le firewall partagé de l'hébergeur.

Audit de sécurité WordPress : 20 points à vérifier

Vingt points d'audit classés par catégorie : mises à jour, authentification, permissions, endpoints exposés, infrastructure.

Mises à jour et inventaire des composants

1. Core WordPress à jour. Vérifier que la version installée est la dernière stable. Le core corrige peu de failles — mais celles qui existent sont exploitées massivement dès leur divulgation.
2. Plugins et thèmes à jour. En 2025, les composants premium présentaient trois fois plus de vulnérabilités exploitables que les composants gratuits. Les thèmes dits « nulled » obtenus sur des sources tierces sont hors périmètre de tout audit sérieux.
3. Plugins inutilisés supprimés, pas seulement désactivés. Un plugin désactivé reste lisible dans le système de fichiers — il peut contenir du code vulnérable qu'un scanner externe détecte.
4. Thèmes inutilisés supprimés. Conserver uniquement le thème actif et, si applicable, son parent.

Authentification et gestion des accès

1. Aucun compte avec le nom d'utilisateur « admin ». C'est le premier identifiant testé par les attaques par force brute automatisées.
2. MFA activé pour tous les comptes éditeurs et administrateurs. Un mot de passe seul ne résiste pas aux attaques de credential stuffing à partir de bases de données compromises.
3. Inventaire des comptes utilisateurs. Supprimer les comptes créés lors d'une ancienne migration ou par un prestataire qui n'intervient plus sur le projet.
4. Rôles minimaux. Un rédacteur n'a pas besoin du rôle Administrateur pour publier un article — chaque privilège superflu est une surface d'attaque.

Permissions fichiers et wp-config.php

1. Permissions 644 sur les fichiers, 755 sur les répertoires. Ce sont les valeurs recommandées par la documentation officielle WordPress. Elles empêchent tout utilisateur non propriétaire d'écrire dans les fichiers.
2. wp-config.php en 400 ou 440. Ce fichier contient les identifiants de base de données et les clés de salage — lisible uniquement par le processus PHP-FPM qui en a besoin.
3. DISALLOW_FILE_EDIT activé dans wp-config.php. Cette constante supprime l'éditeur de fichiers PHP du tableau de bord, vecteur courant après la prise de contrôle d'un compte administrateur.

Endpoints et fichiers exposés

1. xmlrpc.php bloqué côté serveur. Via ce fichier, une seule requête HTTP peut déclencher des centaines de tentatives de connexion grâce à la méthode system.multicall — les rate-limiters côté application ne voient qu'une requête unique.
2. readme.html et license.txt inaccessibles. Ces fichiers révèlent la version exacte de WordPress à n'importe quel scanner automatisé, facilitant le ciblage par des exploits spécifiques à une version.
3. wp-trackback.php bloqué. Inutilisé sur la quasi-totalité des sites modernes, il sert de vecteur de spam et d'attaques par déni de service applicatif.
4. Exécution PHP désactivée dans wp-content/uploads/. Un attaquant qui dépose un fichier dans ce dossier via une faille d'upload ne doit pas pouvoir l'exécuter — c'est le vecteur classique du backdoor.
5. Énumération des utilisateurs via l'API REST bloquée. L'endpoint /wp-json/wp/v2/users/ retourne par défaut les logins de tous les auteurs publics, livrant aux attaquants la première moitié des identifiants de connexion.

Infrastructure et sauvegarde

1. SSL/TLS valide avec renouvellement automatique. Un certificat expiré n'est pas qu'un problème SEO : il expose les sessions utilisateurs et les données transmises en clair.
2. Préfixe de tables MySQL différent de wp_. Réduit l'impact d'une injection SQL en rendant les noms de tables moins prévisibles pour les outils d'exploitation automatisés.
3. En-têtes HTTP de sécurité présents. X-Frame-Options, X-Content-Type-Options, HSTS et Referrer-Policy — vérifiables en 30 secondes via les DevTools ou un outil d'analyse en ligne.
4. Sauvegarde journalière testée. Une sauvegarde non testée est une intention, pas une protection. La restauration doit avoir été vérifiée au moins une fois sur l'environnement de production.

Durcissement Nginx : la configuration complète copiable

Les guides de sécurité WordPress recommandent systématiquement des plugins de sécurité. Ces plugins s'exécutent en PHP : WordPress doit d'abord charger, bootstrapper sa base de données, puis évaluer la requête avant de la bloquer. Chaque attaque consomme des ressources, même celles qui sont bloquées.

Une règle Nginx traitée au niveau du serveur bloque la requête avant d'atteindre PHP. Coût CPU : zéro. Voici le bloc complet à intégrer dans la section server {} de votre virtualhost WordPress :

# ─── Fichiers sensibles WordPress ───────────────────────────────────────────

# xmlrpc.php : vecteur de force brute amplifiée via system.multicall
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

# Fichiers de diagnostic présents dans toute installation WordPress par défaut
location ~* ^/(readme\.html|license\.txt|wp-trackback\.php)$ {
    deny all;
    log_not_found off;
}

# wp-config.php et fichiers de configuration serveur
location ~* (wp-config\.php|wp-config-sample\.php|\.htaccess|\.htpasswd)$ {
    deny all;
    access_log off;
    log_not_found off;
}

# Bloquer l'exécution PHP dans wp-content/uploads (backdoor via upload)
location ~* ^/wp-content/uploads/.*\.php$ {
    deny all;
    log_not_found off;
}

# Limiter wp-login.php à vos plages IP (remplacer par votre CIDR réel)
# Supprimer ce bloc si votre plugin MFA gère lui-même la limitation d'accès
location = /wp-login.php {
    allow 198.51.100.0/24;
    deny all;
}

# ─── En-têtes HTTP de sécurité ───────────────────────────────────────────────

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

# ─── Masquer la version du serveur ───────────────────────────────────────────
# À placer dans le bloc http {} de nginx.conf, pas dans le virtualhost
# server_tokens off;

Après modification, vérifiez la syntaxe avant de recharger :

nginx -t && nginx -s reload

Trois points d'attention avant de déployer :

• Le filtrage wp-login.php par IP bloque aussi vos administrateurs travaillant hors de la plage autorisée. Si votre équipe travaille depuis des adresses variables, remplacez-le par un rate-limit Nginx plutôt qu'un filtrage IP strict.
• HSTS est difficile à annuler pendant la durée du max-age. Ne l'activer qu'une fois HTTPS stable et le certificat renouvelé automatiquement, avant d'ajouter includeSubDomains.
• server_tokens off se place dans le bloc http {} de nginx.conf, pas dans le virtualhost — sinon Nginx refuse de démarrer avec une erreur de directive.

Plugins de sécurité : lequel choisir

La configuration serveur est la priorité. Les plugins de sécurité viennent en complément, pas en remplacement. Trois options répandues sur les parcs d'agences :

Plugin	Points forts	Limite principale
Wordfence	WAF + scanner de malware intégré, alertes en temps réel, base de signatures mise à jour en continu	WAF en mode PHP — chaque requête bloquée charge quand même WordPress ; version gratuite avec 30 jours de délai sur les nouvelles règles
Solid Security (ex-iThemes)	Durcissement applicatif complet : MFA, bannissement automatique, journalisation des actions utilisateurs	Pas de WAF réseau ; détection de malwares limitée sur le code obfusqué
Patchstack	Protection virtuelle (vPatching) : règle déployée dans les heures suivant une divulgation CVE, sans mise à jour du plugin vulnérable	Modèle SaaS ; plan gratuit limité à un seul site avec délai de protection

Pour un parc d'agence, Patchstack présente un avantage structurel : il couvre la fenêtre entre la divulgation d'une CVE et la publication du correctif par le développeur du plugin — c'est précisément là que se concentrent les 46 % de vulnérabilités sans patch au moment de leur divulgation publique.

Intégrer l'audit dans la maintenance mensuelle

Un audit ponctuel perd sa valeur si aucune procédure ne le renouvelle. La surface d'attaque WordPress évolue à chaque nouveau plugin installé, chaque mise à jour de thème, chaque compte créé pour un nouveau client ou un nouveau collaborateur.

Une cadence réaliste pour un parc d'agence :

• Hebdomadaire : vérification automatique des mises à jour disponibles, scan de vulnérabilités, alerte sur les nouvelles CVE affectant les composants en production.
• Mensuel : révision des comptes utilisateurs actifs, vérification des permissions fichiers après toute intervention manuelle, test de restauration d'une sauvegarde récente.
• Trimestriel : relecture complète de la configuration serveur, désinstallation des plugins dormants, rotation des clés de salage WordPress.

La plateforme Sentinelo Sécurité exécute 19 contrôles de sécurité sur chaque site WordPress — hebdomadairement et à la demande — avec croisement WPScan pour les vulnérabilités de plugins et analyse de réputation externe Sucuri. Les résultats alimentent le rapport mensuel envoyé à vos clients sous votre marque. Le scanner gratuit donne une première évaluation sans inscription.

Les mises à jour WordPress, WooCommerce et extensions sont appliquées automatiquement après vérification qu'une sauvegarde de moins de 24 heures est disponible — avec retour arrière automatique si le site cesse de répondre après la mise à jour.

Cas pratique : site WordPress infecté par un backdoor

Voici un scénario représentatif : un site vitrine WordPress géré par une agence présente subitement des redirections vers des pages de phishing. Le client signale le problème un vendredi matin.

Diagnostic initial. L'analyse des journaux Nginx révèle des requêtes POST vers /wp-content/uploads/cache/temp.php depuis des IPs distribuées sur plusieurs pays. Ce fichier n'existait pas dans le dépôt git — il a été déposé via une faille d'upload dans un plugin de formulaire non mis à jour depuis plusieurs mois.

Confinement. Mise en maintenance immédiate, révocation de toutes les sessions WordPress actives et des tokens d'application REST. Inventaire des fichiers PHP modifiés récemment :

find /var/www/monsite -mtime -7 -name "*.php" | sort

Nettoyage. Suppression des fichiers injectés, restauration du plugin depuis les sources officielles WordPress.org, réinitialisation de toutes les clés de salage dans wp-config.php. Mise à jour immédiate de l'ensemble des composants.

Ce qui aurait empêché l'exploitation : la règle Nginx bloquant l'exécution PHP dans /wp-content/uploads/ aurait rendu le backdoor inopérant même après son dépôt. Le fichier aurait été présent sur le serveur, mais aucune requête HTTP n'aurait pu l'exécuter — le point de compromission n'aurait jamais été activé.

Ce scénario illustre pourquoi la maintenance WordPress régulière ne se résume pas aux mises à jour : la configuration serveur est le filet qui limite les dégâts quand une faille passe malgré tout. Pour les parcs multi-sites, externaliser la maintenance WordPress permet de traiter ces incidents sans mobiliser l'équipe technique de l'agence sur chaque site concerné.

Points clés à retenir

• 91 % des vulnérabilités WordPress viennent des plugins — pas du cœur.
• 46 % des failles n'ont aucun patch au moment de leur divulgation : la configuration serveur est le seul rempart immédiat disponible.
• Le durcissement Nginx bloque avant PHP — efficacité maximale, consommation nulle.
• Un audit sans procédure de renouvellement est périmé dès le mois suivant.

Pour mettre en place cette surveillance sur votre parc, la page Sentinelo Sécurité détaille les 19 contrôles exécutés et leur fréquence d'exécution.