Faille de sécurité WordPress : comprendre l’injection SQL, le XSS et l’élévation de privilèges
Une faille de sécurité WordPress est presque toujours une porte d’entrée laissée ouverte par une extension ou un thème mal codé ou plus maintenu. Je le constate sur la majorité des sites que j’interviens en urgence : le cœur de WordPress est solide, mais l’écosystème de plugins autour ne l’est pas toujours. Comprendre les trois mécanismes les plus exploités, l’injection SQL, le XSS et l’élévation de privilèges, permet d’agir avant l’incident plutôt qu’après.
Ces trois failles n’ont pas le même objectif. L’une vise la base de données, l’autre le navigateur des visiteurs, la troisième les droits d’un compte utilisateur. Pourtant, elles partagent souvent la même origine : du code qui fait confiance à une donnée venue de l’extérieur sans la vérifier.
Dans ce guide, j’explique simplement chaque faille, je montre d’où elles viennent le plus souvent, et je détaille ce qui protège réellement un site en production.
Qu’est-ce qu’une faille de sécurité WordPress exactement ?
Une définition simple
Une faille de sécurité est un défaut dans le code qui permet à un attaquant de faire faire au site quelque chose qu’il ne devrait pas faire. Par exemple, lire des données privées, modifier du contenu ou prendre le contrôle d’un compte. WordPress lui-même reçoit des correctifs réguliers, mais la majorité des failles exploitées viennent des extensions tierces.
Pourquoi WordPress est une cible fréquente
WordPress propulse une part très importante des sites web dans le monde. Cette popularité attire mécaniquement les attaquants : un script automatisé qui teste une faille connue peut toucher des milliers de sites en quelques heures. C’est pourquoi un site mal maintenu reste exposé même sans être visé personnellement.
Le rôle central des extensions et thèmes non maintenus
Un plugin abandonné par son auteur ne reçoit plus de correctif. Si une faille y est découverte, elle reste ouverte indéfiniment, sauf si vous changez d’extension. C’est la cause la plus fréquente des compromissions que je constate sur le terrain.
L’injection SQL : comprendre cette faille de sécurité WordPress courante
Le principe de l’injection SQL
Une injection SQL consiste à glisser du code dans un champ de formulaire pour manipuler la base de données du site. Concrètement, si un plugin construit sa requête en collant directement le texte saisi par l’utilisateur, un attaquant peut insérer des instructions supplémentaires. Il peut alors lire des mots de passe, extraire des données clients ou modifier des contenus.
D’où vient le problème en pratique
La faille apparaît quand le code n’utilise pas de requêtes préparées. Une requête préparée sépare la structure de la requête et les données saisies, ce qui empêche l’injection. WordPress fournit cette fonction nativement via sa classe d’accès à la base de données, mais certains plugins mal codés continuent de construire leurs requêtes à la main.
// Mauvaise pratique
$wpdb->query("SELECT * FROM table WHERE id = " . $_GET['id']);
// Bonne pratique avec requête préparée
$wpdb->get_results(
$wpdb->prepare("SELECT * FROM table WHERE id = %d", $_GET['id'])
);Ce qui protège réellement contre l’injection SQL
La première protection est le choix d’extensions bien maintenues, avec des mises à jour régulières. Ensuite, un pare-feu applicatif (WAF) peut bloquer les tentatives les plus courantes avant qu’elles n’atteignent le code. Enfin, limiter les droits du compte de base de données réduit les dégâts en cas de faille exploitée. La documentation officielle des développeurs WordPress détaille d’ailleurs les bonnes pratiques de requêtes préparées, consultable sur developer.wordpress.org.
Le XSS, une autre faille de sécurité WordPress à ne pas négliger
Qu’est-ce que le XSS (cross-site scripting)
Le XSS consiste à injecter du code JavaScript dans une page pour qu’il s’exécute dans le navigateur d’un autre visiteur. Par exemple, un commentaire ou un champ de profil mal filtré peut contenir un script qui vole les cookies de session d’un administrateur connecté.
Les deux formes principales
Le XSS réfléchi s’exécute immédiatement via un lien piégé envoyé à la victime. Le XSS stocké, plus dangereux, enregistre le script dans la base de données : il s’exécute alors pour chaque visiteur de la page, y compris les administrateurs. C’est souvent ce second type qui mène à une prise de contrôle complète.
Comment on s’en protège concrètement
WordPress propose des fonctions d’échappement comme esc_html() ou esc_attr(), qui neutralisent le code avant de l’afficher. Un développeur sérieux les utilise systématiquement sur toute donnée affichée venant d’un utilisateur. Par ailleurs, une politique de sécurité des contenus (CSP) dans les en-têtes HTTP limite ce qu’un script injecté peut faire, même s’il s’exécute.
L’élévation de privilèges : la faille de sécurité WordPress la plus discrète
Le principe de l’élévation de privilèges
Cette faille permet à un compte aux droits limités, par exemple un simple abonné, d’obtenir les droits d’un administrateur. L’attaquant n’a donc pas besoin de deviner un mot de passe : il crée un compte normal, puis exploite une faille pour monter en droits.
Pourquoi elle est difficile à détecter
Contrairement à un piratage visible avec un site défiguré, l’élévation de privilèges est silencieuse. L’attaquant peut créer un second compte administrateur caché et l’utiliser des mois plus tard. C’est pourquoi je recommande de vérifier régulièrement la liste des comptes administrateurs, pas seulement au moment d’un incident.
Ce qui limite ce risque
Appliquer le principe du moindre privilège est la meilleure protection : chaque compte ne doit avoir que les droits strictement nécessaires à son usage. Ensuite, l’authentification à deux facteurs complique fortement la prise de contrôle d’un compte existant. Enfin, un audit régulier des rôles utilisateurs permet de repérer une anomalie rapidement, comme détaillé dans mon article sur le durcissement avancé des rôles utilisateurs et de l’API REST.
D’où viennent vraiment ces failles de sécurité WordPress
Les extensions non maintenues, cause numéro un
Un plugin installé il y a plusieurs années et jamais mis à jour accumule les vulnérabilités connues publiquement. Les bases de données de failles référencent ces plugins, et les attaquants les consultent en premier. Désinstaller une extension abandonnée reste plus sûr que de la garder « parce qu’elle fonctionne encore ».
Les thèmes personnalisés mal codés
Un thème développé rapidement, sans revue de sécurité, contient souvent les mêmes erreurs : requêtes non préparées, données non échappées à l’affichage. Ce risque est encore plus élevé sur les thèmes gratuits téléchargés hors des répertoires officiels.
Le tableau récapitulatif des trois failles
| Faille | Cible | Origine fréquente | Protection principale |
|---|---|---|---|
| Injection SQL | Base de données | Requêtes non préparées dans un plugin | Requêtes préparées, WAF |
| XSS | Navigateur des visiteurs | Données non échappées à l’affichage | Échappement, en-têtes CSP |
| Élévation de privilèges | Comptes utilisateurs | Contrôle d’accès mal codé | Moindre privilège, audit des rôles |
Comment réduire le risque de faille de sécurité WordPress sur votre site
La procédure que j’applique en intervention
- Lister toutes les extensions et thèmes installés, actifs ou non.
- Identifier ceux qui ne sont plus mis à jour depuis longtemps.
- Supprimer les extensions inutiles, même désactivées.
- Mettre à jour le cœur WordPress, les thèmes et les plugins conservés.
- Vérifier la liste des comptes administrateurs et leurs rôles.
- Mettre en place l’authentification à deux facteurs sur les comptes à privilèges.
- Installer un pare-feu applicatif pour filtrer les tentatives connues.
Ce qui ne protège pas vraiment
Cacher la version de WordPress ou renommer la page de connexion ralentit un peu les attaques automatisées basiques. Cependant, cela ne remplace jamais la correction du code vulnérable lui-même. Un audit complet reste la seule façon de savoir où se situent les vrais risques, comme je le décris dans mon article sur l’audit de sécurité WordPress en huit points.
Le suivi dans la durée
Une faille corrigée aujourd’hui ne garantit rien pour demain. De nouvelles vulnérabilités sont découvertes régulièrement sur des extensions très utilisées. Un monitoring régulier des mises à jour disponibles, décrit dans mon article sur le monitoring WordPress, permet de réagir avant l’exploitation.
Questions fréquentes
Comment savoir si mon site a une faille de sécurité WordPress ?
Un audit de sécurité analyse les extensions, les thèmes, les comptes et la configuration serveur. Sans audit, un site peut sembler normal tout en contenant une faille connue. C’est le seul moyen fiable de vérifier.
Une extension à jour peut-elle quand même contenir une faille ?
Oui, une faille peut exister avant d’être découverte publiquement. Cependant, une extension à jour reçoit le correctif dès qu’elle est signalée. Une extension abandonnée, elle, reste vulnérable indéfiniment.
L’injection SQL touche-t-elle uniquement les gros sites ?
Non, la taille du site n’a aucun rapport avec le risque. Un petit site avec un plugin de formulaire vulnérable est tout aussi exposé qu’un site à fort trafic. Les attaques sont souvent automatisées et ciblent des failles, pas des sites précis.
Le XSS peut-il affecter les visiteurs sans toucher l’administrateur ?
Oui, un script injecté peut voler les cookies ou rediriger n’importe quel visiteur, pas seulement un administrateur. Le risque est plus grave quand l’administrateur est visé, car il mène souvent à une prise de contrôle complète du site.
Ce qu’il faut retenir sur la faille de sécurité WordPress
L’injection SQL, le XSS et l’élévation de privilèges partagent une même origine fréquente : des extensions et thèmes non maintenus. Garder un site à jour, limiter les droits des comptes et surveiller les mises à jour disponibles réduit fortement le risque. Je propose l’audit de sécurité WordPress pour faire ce diagnostic sur votre site.
