Comment auditer la securite WordPress de votre entreprise en 7 etapes — guide methodique 2026

WordPress propulse plus de 43% des sites web dans le monde en 2026. Cette domination en fait mecaniquement la cible privilegiee des attaquants : chaque vulnerabilite decouverte dans le coeur de WordPress, dans un plugin populaire ou dans un theme expose potentiellement des millions de sites a une compromission. La recente vulnerabilite wp2shell (CVE-2026-63030), une faille pre-auth RCE affectant WordPress depuis la version 5.6, a rappele brutalement que meme le coeur du CMS peut devenir un vecteur d'attaque devastateur.

Pour les entreprises francaises — PME, ETI ou grands comptes — dont le site vitrine, le e-commerce ou l'intranet repose sur WordPress, un audit de securite regulier n'est plus un luxe mais une obligation operationnelle. Ce guide vous donne une methodologie en 7 etapes, reproductible et actionnable, pour evaluer et renforcer la securite de votre installation WordPress.

— Etape 1 : Verifier les versions de WordPress, PHP et de la base de donnees

La premiere etape de tout audit de securite WordPress consiste a etablir un etat des lieux des versions logicielles en production. Un WordPress obsolete est un WordPress vulnerable — c'est aussi simple que cela. La vulnerabilite wp2shell (CVE-2026-63030) affecte toutes les versions de WordPress depuis la 5.6, ce qui signifie que des sites n'ayant pas applique les correctifs depuis des mois, voire des annees, sont exposes a une execution de code arbitraire sans authentification.

Commencez par verifier la version de WordPress installée avec WP-CLI :

# Verifier la version WordPress actuelle
wp core version

# Verifier les mises a jour disponibles
wp core check-update

# Verifier la version PHP du serveur
php -v

# Verifier la version MySQL/MariaDB
wp db query "SELECT VERSION();"

En juillet 2026, les versions supportees sont WordPress 7.0.2 (branche majeure) et 6.9.5 (branche de maintenance). Cote PHP, la version minimale acceptable est PHP 8.1, mais nous recommandons PHP 8.3 ou superieur pour beneficier des dernieres corrections de securite et des performances optimales. Les versions PHP 7.x sont en fin de vie depuis janvier 2024 et ne recoivent plus aucun correctif de securite — si votre serveur tourne encore sur PHP 7.4, c'est une urgence.

Pour MySQL, assurez-vous d'utiliser MySQL 8.0+ ou MariaDB 10.6+. Les versions anterieures presentent des vulnerabilites connues d'escalade de privileges et de contournement d'authentification. Documentez chaque version dans votre rapport d'audit avec le statut de support (maintenue, fin de vie, obsolete) et la date du dernier patch applique.

— Etape 2 : Auditer les plugins et themes installes

Les plugins et les themes constituent la surface d'attaque la plus large d'une installation WordPress. Selon les donnees de WPScan, plus de 90% des vulnerabilites WordPress proviennent des extensions tierces, pas du coeur du CMS. Un site d'entreprise moyen utilise entre 15 et 30 plugins — chacun d'eux est un point d'entree potentiel pour un attaquant.

# Lister tous les plugins actifs avec leur version et statut de mise a jour
wp plugin list --status=active --format=table

# Lister les plugins inactifs (a supprimer)
wp plugin list --status=inactive --format=table

# Verifier les mises a jour disponibles pour les plugins
wp plugin list --update=available --format=table

# Lister tous les themes installes
wp theme list --format=table

# Verifier l'integrite des plugins officiels
wp plugin verify-checksums --all

Lors de votre audit, identifiez systematiquement les plugins qui n'ont pas recu de mise a jour depuis plus de 12 mois — c'est generalement le signe d'un abandon par le developpeur. Un plugin abandonne est un plugin qui ne recevra jamais de correctif de securite, meme si une vulnerabilite critique est decouverte. Supprimez-le et cherchez une alternative maintenue activement.

Verifiez egalement la reputation de chaque plugin sur WordPress.org : nombre d'installations actives, note moyenne, derniere mise a jour, compatibilite avec votre version de WordPress. Croisez ces informations avec la base de donnees WPScan Vulnerability Database pour identifier les plugins presentant des vulnerabilites connues non corrigees. Enfin, supprimez tous les plugins et themes inactifs — meme desactives, ils restent accessibles sur le serveur et peuvent etre exploites directement.

— Etape 3 : Analyser la configuration wp-config.php et les permissions fichiers

Le fichier wp-config.php est le coeur nevralgique de la configuration WordPress. Il contient les identifiants de base de donnees, les cles de securite, et les constantes de configuration qui determinent le niveau de securite de votre installation. Un wp-config.php mal configure est une porte ouverte sur votre infrastructure.

# Verifier les permissions du fichier wp-config.php (devrait etre 600 ou 640)
stat -c "%a %n" wp-config.php

# Rechercher les fichiers avec des permissions trop permissives (777)
find . -type f -perm 777 -ls

# Rechercher les repertoires avec des permissions trop permissives
find . -type d -perm 777 -ls

# Verifier les permissions recommandees
# Repertoires : 755 | Fichiers : 644 | wp-config.php : 600

Votre checklist de verification de wp-config.php doit inclure les points suivants. Premierement, verifiez que les cles de securite et les sels (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY et leurs variantes SALT) sont bien definis avec des valeurs uniques et aleatoires. Si ces cles sont encore a leur valeur par defaut ou vides, regenerez-les immediatement via l'API WordPress.

Deuxiemement, assurez-vous que les constantes de securite critiques sont correctement definies :

// Desactiver l'editeur de fichiers integre (empeche la modification de code via l'admin)
define('DISALLOW_FILE_EDIT', true);

// Desactiver le mode debug en production
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

// Forcer SSL pour l'administration
define('FORCE_SSL_ADMIN', true);

// Limiter les revisions de posts (reduit la taille de la BDD)
define('WP_POST_REVISIONS', 5);

// Desactiver les mises a jour automatiques du coeur (si gerees manuellement)
define('WP_AUTO_UPDATE_CORE', 'minor');

Troisiemement, verifiez que le prefixe de la base de donnees n'est pas le defaut wp_. Bien que ce ne soit pas une mesure de securite forte en soi, cela complique les attaques par injection SQL automatisees qui ciblent les noms de tables par defaut. Sur un site existant, le changement de prefixe necessite une migration de base de donnees — documentez-le comme une recommandation pour les futurs deploiements si la modification en production est trop risquee.

— Etape 4 : Renforcer l'authentification et les acces

L'authentification est la premiere ligne de defense de votre WordPress. Les attaques par force brute sur /wp-login.php et /wp-admin/ representent une part significative du trafic malveillant observe sur les sites WordPress. Sans protections adequates, un attaquant peut tester des milliers de combinaisons identifiant/mot de passe par minute.

Voici les mesures a verifier et a mettre en place :

Imposer des mots de passe forts. WordPress 7.x integre nativement un generateur de mots de passe robustes, mais rien n'empeche un administrateur de le contourner. Utilisez un plugin de politique de mots de passe pour forcer une longueur minimale de 14 caracteres, l'utilisation de majuscules, minuscules, chiffres et caracteres speciaux, et l'expiration periodique des mots de passe (tous les 90 jours pour les comptes administrateurs).

Activer l'authentification a deux facteurs (2FA). La 2FA est la mesure la plus efficace contre le vol de credentials. Deployer une solution TOTP (Time-based One-Time Password) compatible avec Google Authenticator ou Authy pour tous les comptes ayant des privileges d'edition ou d'administration. Les plugins comme WP 2FA ou Two Factor Authentication permettent une implementation sans friction.

Limiter les tentatives de connexion. Configurez un mecanisme de verrouillage temporaire apres 5 tentatives echouees (lockout de 30 minutes, puis progressif). Cette mesure neutralise les attaques par force brute sans impacter les utilisateurs legitimes qui font une simple faute de frappe.

// Desactiver XML-RPC si non utilise (elimine un vecteur de brute force)
add_filter('xmlrpc_enabled', '__return_false');

// Ajouter dans .htaccess pour bloquer l'acces a xmlrpc.php
// <Files xmlrpc.php>
//   Order Deny,Allow
//   Deny from all
// </Files>

Reviser les roles et les comptes utilisateurs. Listez tous les comptes administrateurs et verifiez qu'ils sont tous legitimes et necessaires. Supprimez le compte admin par defaut s'il existe encore, et renommez tout compte dont le login est previsible. Appliquez le principe du moindre privilege : un redacteur n'a pas besoin des droits administrateur. Utilisez les application passwords pour les acces API plutot que les identifiants du compte principal.

— Etape 5 : Deployer un WAF et durcir les en-tetes HTTP

Un Web Application Firewall (WAF) constitue une couche de defense essentielle entre Internet et votre WordPress. Il filtre le trafic malveillant avant qu'il n'atteigne votre application, bloquant les tentatives d'injection SQL, de cross-site scripting (XSS), de path traversal et d'autres attaques courantes. Trois approches principales s'offrent a vous : un WAF cloud (Cloudflare Pro/Business, Sucuri Firewall), un WAF au niveau du serveur (ModSecurity avec les regles OWASP CRS), ou un WAF applicatif via plugin (Wordfence, NinjaFirewall).

Parallelement au WAF, le durcissement des en-tetes HTTP est une mesure defensive souvent negligee mais extremement efficace. Ajoutez les en-tetes suivantes dans votre configuration Apache ou Nginx :

# En-tetes de securite a ajouter dans .htaccess (Apache) ou nginx.conf

# Empecher le clickjacking
Header always set X-Frame-Options "SAMEORIGIN"

# Empecher le MIME type sniffing
Header always set X-Content-Type-Options "nosniff"

# Forcer HTTPS (HSTS) - 1 an avec sous-domaines
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

# Politique de referrer
Header always set Referrer-Policy "strict-origin-when-cross-origin"

# Politique de permissions (desactiver camera, micro, geolocalisation)
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

# Content Security Policy (a adapter selon votre site)
Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;"

Verifiez egalement que l'acces aux fichiers sensibles est bloque au niveau du serveur web. Les fichiers wp-config.php, .htaccess, xmlrpc.php, readme.html et license.txt ne doivent pas etre accessibles depuis le navigateur. Mettez en place un rate limiting sur /wp-login.php et /wp-json/ pour limiter les abus (10 requetes par minute sur le login, 60 par minute sur l'API REST).

— Etape 6 : Mettre en place des sauvegardes automatisees et testees

Les sauvegardes sont votre dernier filet de securite. Si toutes les mesures de prevention echouent et que votre site est compromis, seule une sauvegarde saine vous permettra de restaurer votre activite en ligne dans un delai acceptable. Pourtant, trop d'entreprises decouvrent au moment de la crise que leurs sauvegardes sont inexistantes, corrompues, ou stockees sur le meme serveur que le site compromis.

Appliquez la regle 3-2-1 : 3 copies de vos donnees, sur 2 types de supports differents, dont 1 copie hors site. Concretement, cela signifie une sauvegarde locale sur le serveur (pour les restaurations rapides), une copie sur un stockage distant (Amazon S3, Backblaze B2, ou un serveur dedie), et une copie supplementaire sur un support physique ou un autre fournisseur cloud.

# Exporter la base de donnees avec WP-CLI
wp db export backup-$(date +%Y%m%d-%H%M%S).sql --add-drop-table

# Sauvegarde complete du site avec rsync (vers un serveur distant)
rsync -avz --delete /var/www/wordpress/ backup-server:/backups/wordpress/

# Script de sauvegarde quotidienne (a ajouter dans crontab)
# 0 3 * * * wp db export /backups/db/wp-$(date +\%Y\%m\%d).sql --path=/var/www/wordpress
# 0 4 * * 0 tar -czf /backups/full/wp-full-$(date +\%Y\%m\%d).tar.gz /var/www/wordpress

# Verifier l'integrite d'une sauvegarde SQL
wp db import backup.sql --dry-run 2>&1 | tail -5

La frequence de sauvegarde depend de la frequence de modification de votre site. Pour un site e-commerce ou un site avec des formulaires de contact reguliers, une sauvegarde quotidienne de la base de donnees est le minimum. Pour les fichiers (themes, plugins, uploads), une sauvegarde hebdomadaire suffit generalement. Les solutions comme UpdraftPlus (version gratuite ou premium), BackWPup ou VaultPress/Jetpack Backup automatisent ce processus et offrent des options de stockage distant integrees.

Point critique : testez vos restaurations. Une sauvegarde que vous n'avez jamais testee n'est pas une sauvegarde — c'est un espoir. Planifiez un test de restauration complet au moins une fois par trimestre sur un environnement de staging. Mesurez le temps de restauration (RTO) et verifiez l'integrite fonctionnelle du site restaure. Documentez la procedure pour que n'importe quel membre de l'equipe puisse l'executer en situation de crise.

— Etape 7 : Implementer le monitoring et la detection d'intrusion

La derniere etape de votre audit consiste a mettre en place les mecanismes de surveillance qui vous permettront de detecter une compromission le plus rapidement possible. Le temps moyen de detection d'une intrusion dans une PME est de 197 jours selon le rapport IBM Cost of a Data Breach 2025. Avec un monitoring adequat, ce delai peut etre reduit a quelques heures.

Monitoring de l'integrite des fichiers. WordPress fournit un mecanisme integre via WP-CLI pour verifier que les fichiers du coeur n'ont pas ete modifies. Automatisez cette verification :

# Verifier l'integrite du coeur WordPress
wp core verify-checksums

# Verifier l'integrite de tous les plugins officiels
wp plugin verify-checksums --all

# Lister les fichiers modifies dans les dernieres 24 heures
find /var/www/wordpress -type f -mtime -1 -name "*.php" -ls

# Rechercher des webshells courants (patterns suspects dans les fichiers PHP)
grep -r "eval(" --include="*.php" /var/www/wordpress/wp-content/
grep -r "base64_decode" --include="*.php" /var/www/wordpress/wp-content/
grep -r "system(" --include="*.php" /var/www/wordpress/wp-content/

Monitoring des acces et des logs. Configurez la journalisation detaillee des acces a l'interface d'administration, des tentatives de connexion echouees, des modifications de fichiers et des changements de configuration. Le plugin WP Activity Log (anciennement WP Security Audit Log) enregistre plus de 700 evenements differents et peut envoyer des alertes en temps reel par email ou vers un SIEM.

Alertes a configurer imperativement : creation ou modification d'un compte administrateur, modification de fichiers du coeur WordPress, installation ou activation d'un plugin, modification de wp-config.php, tentatives de connexion echouees depassant le seuil (plus de 10 en 5 minutes), et connexions depuis des adresses IP ou des pays inhabituels.

Planning de scans de securite. Mettez en place un scan automatise hebdomadaire avec un outil comme WPScan (en ligne de commande ou via l'API) pour detecter les vulnerabilites connues dans vos plugins, themes et la version WordPress. Completez par un audit manuel approfondi chaque trimestre, incluant une revue des logs, un test de penetration cible et une verification de la conformite des configurations.

— Checklist recapitulative : les 7 etapes en un coup d'oeil