Pourquoi la sécurité WordPress est un enjeu critique en 2025

WordPress propulse aujourd’hui plus de 43 % des sites web dans le monde. Cette hégémonie en fait mécaniquement la cible privilégiée des hackers : selon le rapport Sucuri 2024, 90 % des CMS nettoyés après un piratage étaient des sites WordPress.

Mais attention à un raccourci trompeur : ce n’est pas WordPress lui-même qui est vulnérable. C’est l’écosystème qui l’entoure — plugins, thèmes, configurations serveur — et surtout les pratiques des administrateurs qui ouvrent la porte aux attaquants.

Chez Lueur Externe, nous auditons et sécurisons des sites WordPress depuis plus de 20 ans. Voici les 10 failles de sécurité les plus courantes que nous rencontrons, accompagnées de solutions concrètes pour y remédier.

1. Plugins et thèmes obsolètes : la faille n°1

Le problème

D’après Patchstack, plus de 50 % des vulnérabilités WordPress exploitées proviennent de plugins non mis à jour. Un simple formulaire de contact, un slider ou un builder de pages peut devenir une porte d’entrée si son éditeur a corrigé une faille que vous n’avez pas encore appliquée.

Exemple concret : en 2024, une vulnérabilité critique dans le plugin LiteSpeed Cache (CVE-2024-28000) a exposé plus de 5 millions de sites à une prise de contrôle complète.

La solution

  • Activez les mises à jour automatiques pour les correctifs de sécurité mineurs.
  • Planifiez une revue hebdomadaire des mises à jour majeures sur un environnement de staging.
  • Supprimez tout plugin ou thème inactif : même désactivé, son code reste accessible.

2. Mots de passe faibles et attaques par force brute

Le problème

L’attaque par force brute consiste à tester des milliers de combinaisons identifiant/mot de passe sur la page /wp-login.php. Avec des outils comme WPScan ou Hydra, un attaquant peut tenter plusieurs dizaines de milliers de combinaisons par heure.

En 2024, le mot de passe admin123 figurait encore dans le top 10 des credentials les plus utilisés sur les sites WordPress piratés (source : Wordfence).

La solution

  • Imposez des mots de passe de 16 caractères minimum mêlant majuscules, minuscules, chiffres et caractères spéciaux.
  • Limitez les tentatives de connexion avec un plugin comme Limit Login Attempts Reloaded.
  • Activez l’authentification à deux facteurs (2FA) pour tous les comptes administrateurs.
  • Changez l’URL de connexion par défaut.

3. Injections SQL (SQLi)

Le problème

Une injection SQL survient lorsqu’un attaquant insère du code SQL malveillant dans un champ de formulaire ou un paramètre d’URL mal protégé. Résultat : il peut lire, modifier ou supprimer l’intégralité de votre base de données.

WordPress utilise la classe $wpdb qui offre des méthodes de requêtes préparées. Le problème apparaît quand des développeurs de plugins construisent des requêtes SQL brutes sans échappement.

Exemple de code vulnérable vs. sécurisé

// ❌ VULNÉRABLE : concaténation directe
$results = $wpdb->get_results(
  "SELECT * FROM wp_users WHERE user_login = '" . $_GET['user'] . "'"
);

// ✅ SÉCURISÉ : requête préparée avec $wpdb->prepare()
$results = $wpdb->get_results(
  $wpdb->prepare(
    "SELECT * FROM wp_users WHERE user_login = %s",
    sanitize_text_field( $_GET['user'] )
  )
);

La solution

  • Utilisez systématiquement $wpdb->prepare() pour toute requête dynamique.
  • Validez et assainissez toutes les entrées utilisateur (sanitize_text_field(), intval(), etc.).
  • Effectuez un audit de code sur vos plugins custom.

4. Cross-Site Scripting (XSS)

Le problème

Le XSS permet à un attaquant d’injecter du JavaScript malveillant dans les pages vues par d’autres utilisateurs. Cela peut servir à voler des cookies de session, rediriger vers des sites de phishing ou injecter du contenu frauduleux.

Selon WPScan, le XSS représente environ 47 % de toutes les vulnérabilités de plugins WordPress répertoriées en 2024.

La solution

  • Échappez systématiquement les sorties avec esc_html(), esc_attr(), esc_url() et wp_kses().
  • Implémentez une Content Security Policy (CSP) stricte via les headers HTTP.
  • Formez vos développeurs aux bonnes pratiques OWASP.

5. Cross-Site Request Forgery (CSRF)

Le problème

Une attaque CSRF exploite la session authentifiée d’un administrateur pour lui faire exécuter des actions à son insu : modifier un mot de passe, ajouter un utilisateur, publier du contenu. Il suffit d’un lien piégé dans un e-mail ou un commentaire.

La solution

WordPress intègre un système de nonces (number used once) qu’il faut utiliser dans tous les formulaires et requêtes AJAX :

// Génération du nonce dans le formulaire
wp_nonce_field( 'mon_action_securisee', 'mon_nonce' );

// Vérification côté traitement
if ( ! wp_verify_nonce( $_POST['mon_nonce'], 'mon_action_securisee' ) ) {
    wp_die( 'Requête non autorisée.' );
}

6. Permissions de fichiers mal configurées

Le problème

Des permissions trop permissives sur le serveur permettent à un attaquant de modifier des fichiers critiques comme wp-config.php ou d’écrire dans le répertoire /wp-content/uploads/.

Les permissions recommandées

ÉlémentPermission recommandée
Répertoires755
Fichiers644
wp-config.php440 ou 400
.htaccess644
/wp-content/uploads/755 (jamais 777)

La solution

  • Ne jamais utiliser 777 en production.
  • Vérifiez les permissions après chaque migration ou mise à jour serveur.
  • Ajoutez dans wp-config.php : define('DISALLOW_FILE_EDIT', true); pour désactiver l’éditeur de fichiers dans l’administration.

7. Absence de certificat SSL/TLS

Le problème

Un site sans HTTPS transmet les identifiants de connexion et les données des formulaires en clair. En 2025, c’est non seulement un risque de sécurité majeur, mais aussi un handicap SEO : Google pénalise les sites non HTTPS dans ses classements.

Selon W3Techs, environ 15 % des sites WordPress n’utilisent toujours pas le HTTPS en configuration complète.

La solution

  • Installez un certificat SSL (Let’s Encrypt est gratuit).
  • Forcez la redirection HTTP → HTTPS dans votre .htaccess ou via votre hébergeur.
  • Ajoutez le header Strict-Transport-Security (HSTS) pour empêcher tout retour en HTTP.

8. Énumération des utilisateurs

Le problème

Par défaut, WordPress permet de découvrir les identifiants des utilisateurs via une simple requête du type votresite.com/?author=1. L’attaquant obtient ainsi le login admin et n’a plus qu’à deviner le mot de passe.

La solution

  • Bloquez l’énumération via une règle dans .htaccess :
# Bloquer l'énumération des utilisateurs
RewriteCond %{QUERY_STRING} ^author=([0-9]*)
RewriteRule .* - [F,L]
  • Utilisez un identifiant différent du nom affiché publiquement.
  • Désactivez l’API REST pour les utilisateurs non authentifiés si elle n’est pas nécessaire.

9. Hébergement mutualisé non sécurisé

Le problème

Sur un hébergement mutualisé low-cost, votre site partage le même serveur que des dizaines d’autres sites. Si l’un d’eux est compromis, l’attaquant peut potentiellement accéder aux fichiers voisins. On parle de cross-site contamination.

Nous constatons régulièrement, lors de nos audits chez Lueur Externe, que des sites WordPress parfaitement maintenus sont infectés à cause d’un voisin de serveur négligent.

La solution

  • Privilégiez un hébergement isolé : VPS, serveur dédié ou conteneur cloud.
  • Si vous restez en mutualisé, choisissez un hébergeur qui isole réellement les comptes (CageFS, CloudLinux).
  • Chez Lueur Externe, certifiés AWS Solutions Architect, nous déployons des architectures cloud sécurisées et évolutives, avec isolation complète par site.

10. Absence de sauvegardes et de plan de reprise

Le problème

Ce n’est pas une faille technique à proprement parler, mais c’est l’erreur qui transforme un incident mineur en catastrophe. 38 % des petites entreprises ne disposent d’aucune sauvegarde récente et testée de leur site (source : Acronis Cyber Protection Report 2024).

Sans sauvegarde, une attaque par ransomware, une injection de code ou même une erreur humaine peuvent entraîner la perte définitive de votre site.

La solution

  • Mettez en place des sauvegardes quotidiennes automatisées (fichiers + base de données).
  • Stockez les sauvegardes sur un emplacement distant (Amazon S3, Google Cloud Storage).
  • Testez la restauration au moins une fois par trimestre.
  • Documentez un plan de reprise d’activité (PRA) avec des délais précis.

Récapitulatif : les 10 failles et leur niveau de risque

#FailleRisqueDifficulté de correction
1Plugins/thèmes obsolètes🔴 CritiqueFacile
2Mots de passe faibles / force brute🔴 CritiqueFacile
3Injection SQL🔴 CritiqueMoyenne
4Cross-Site Scripting (XSS)🟠 ÉlevéMoyenne
5CSRF🟠 ÉlevéMoyenne
6Permissions fichiers🟠 ÉlevéFacile
7Absence de SSL/TLS🟡 MoyenFacile
8Énumération utilisateurs🟡 MoyenFacile
9Hébergement non sécurisé🟠 ÉlevéMoyenne
10Absence de sauvegardes🔴 CritiqueFacile

Les headers de sécurité HTTP à ne pas oublier

Au-delà des 10 failles listées, un point souvent négligé concerne les en-têtes de sécurité HTTP. Ils constituent une couche de protection supplémentaire, facile à mettre en place et très efficace.

Voici les headers indispensables à ajouter dans votre configuration Apache ou Nginx :

# Headers de sécurité essentiels
Header set X-Content-Type-Options "nosniff"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-XSS-Protection "1; mode=block"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "geolocation=(), microphone=(), camera=()"
Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline';"
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"

Vous pouvez tester la note de sécurité de vos headers sur securityheaders.com. Visez au minimum la note A.

Checklist rapide : sécurisez votre WordPress en 15 minutes

Si vous ne deviez retenir que les actions les plus impactantes, voici une checklist à appliquer immédiatement :

  • ✅ Mettre à jour WordPress, plugins et thèmes
  • ✅ Supprimer les extensions et thèmes inutilisés
  • ✅ Imposer des mots de passe forts + 2FA
  • ✅ Installer un certificat SSL et forcer HTTPS
  • ✅ Changer le préfixe par défaut des tables (wp_)
  • ✅ Désactiver l’édition de fichiers dans l’admin
  • ✅ Bloquer l’énumération des utilisateurs
  • ✅ Configurer les permissions de fichiers
  • ✅ Ajouter les headers de sécurité HTTP
  • ✅ Planifier des sauvegardes automatiques quotidiennes

Ces actions couvrent 80 % des vecteurs d’attaque les plus courants. Pour les 20 % restants — audit de code personnalisé, WAF (Web Application Firewall), monitoring en temps réel, durcissement serveur — l’intervention d’un expert est recommandée.

Conclusion : la sécurité n’est pas une option, c’est un investissement

Chaque jour, des milliers de sites WordPress sont compromis. La plupart auraient pu être protégés avec des mesures simples, appliquées avec rigueur et régularité.

La sécurité WordPress ne se résume pas à installer un plugin “tout-en-un”. C’est une démarche globale qui englobe le code, le serveur, les pratiques d’administration et la maintenance continue.

Depuis 2003, Lueur Externe accompagne les entreprises dans la sécurisation de leurs sites WordPress, Prestashop et sur des architectures cloud AWS. Notre expertise certifiée nous permet de proposer des audits complets, des plans de remédiation concrets et des contrats de maintenance préventive.

Votre site WordPress est-il réellement protégé ? Ne laissez pas le hasard décider. Contactez nos experts pour un audit de sécurité personnalisé et mettez votre activité en ligne à l’abri des menaces.

👉 Demandez votre audit de sécurité WordPress