Protéger WordPress : Comment Réduire les Risques d’Injections SQL

WordPress est solide, mais comme tout logiciel extensible, il devient aussi le reflet de ce qu’on y branche. Un thème qui ajoute des champs, un plugin qui crée un endpoint, un formulaire “rapide” qui parle à la base de données, et vous avez une surface d’attaque qui grandit sans bruit. Parmi les risques les plus tenaces, il y a l’injection SQL. Elle ne s’exprime pas forcément par des “hacks spectaculaires”. Le plus souvent, elle se manifeste par une requête mal construite, des données inattendues qui passent, puis des comportements bizarres côté base de données, parfois sans trace évidente côté front.

L’objectif ici n’est pas d’aspirer à une perfection abstraite. C’est de réduire le risque, rendre l’exploitation difficile et, surtout, empêcher que des entrées utilisateur finissent dans des requêtes SQL de manière dangereuse. Je vais donc parler en termes concrets, centrés sur ce que vous pouvez corriger dans WordPress et dans le code de vos extensions.

Comprendre le mécanisme, sans dramatiser

Une injection SQL apparaît quand une entrée utilisateur influence directement une requête, et que cette influence n’est pas correctement encadrée. Le scénario typique ressemble à ceci :

Une requête est construite en concaténant des morceaux de texte.
L’entrée utilisateur contient des caractères qui changent le sens de la requête. 3) Le serveur exécute alors la requête modifiée.

Ce qui rend le problème délicat dans l’écosystème WordPress, c’est qu’il ne suffit pas de “nettoyer” les données. Beaucoup de développeurs pensent qu’un sanitize_text_field() suffit parce que cela retire des caractères “utiles à l’attaque”. En réalité, la protection contre l’injection SQL ne se joue pas au niveau d’un nettoyage superficiel, elle se joue au niveau de la façon dont la requête est construite et envoyée au moteur SQL.

Dans WordPress, on passe par $wpdb, et surtout par les requêtes préparées. Tant que vous restez dans le modèle “requête préparée + paramètres typés”, vous gagnez une défense fondamentale. À l’inverse, dès que vous commencez à fabriquer du SQL avec des chaînes provenant des utilisateurs, vous ouvrez une porte.

Où l’injection SQL peut réellement se cacher dans WordPress

Dans un site WordPress “standard”, la base de données est déjà utilisée par le core et par les plugins. Le risque augmente surtout dans les cas où du code prend des entrées et les transforme en requêtes.

On rencontre généralement des points de fragilité dans :

Les formulaires personnalisés (recherche, inscription privée, ajout de données, filtres). Les endpoints REST (y compris quand ils sont “internes”, accessibles via l’API). Les actions AJAX (par exemple via admin-ajax.php). Les shortcodes qui acceptent des attributs et qui utilisent ces attributs dans des requêtes. Les imports et synchronisations (où une entrée peut venir d’un fichier, mais aussi d’un champ paramétrable).

Un piège fréquent est le “cas rare” : une requête n’est exécutée que si un paramètre est présent. Le jour où quelqu’un explore l’endpoint, c’est justement là que la faille se révèle.

La règle d’or : requêtes préparées avec $wpdb->prepare()

Si vous ne deviez retenir qu’un mécanisme, ce serait celui-ci : construire les requêtes avec des placeholders, et fournir les valeurs séparément. Dans WordPress, $wpdb->prepare() est votre meilleure barrière.

Voici un exemple représentatif d’une approche risquée, souvent vue quand quelqu’un “garde ça simple” :

// Exposition typique si $user_id vient de $_GET ou $_POST $sql = "SELECT * FROM $wpdbusers WHERE ID = $user_id"; $rows = $wpdbget_results($sql);

Le problème n’est pas que $user_id soit “sale”. Le problème est qu’il devient un morceau de SQL. Si la valeur contient des caractères qui modifient la logique de la requête, vous perdez le contrôle.

À l’inverse, la version robuste suit un modèle :

$user_id = isset($_GET['user_id']) ? $_GET['user_id'] : 0; $sql = $wpdbprepare( "SELECT * FROM $wpdbusers WHERE ID = %d", $user_id ); $rows = $wpdb->get_results($sql);

Le placeholder %d force une conversion attendue pour un entier (et la couche prépare la requête de manière sûre). Vous pouvez utiliser d’autres types selon le besoin, mais l’idée reste la même : ce n’est plus l’entrée qui s’assemble au SQL, c’est le SQL qui attend des paramètres.

Dans une démarche de protection site WordPress, ce point est plus important que la plupart des “filtres” HTML ou la validation côté formulaire. La requête préparée vise directement la classe de vulnérabilité.

Ne confondez pas “échapper” et “préparer”

Beaucoup d’outils proposent des fonctions de type “escape” ou “sanitize”. Elles sont utiles, mais elles ne remplacent pas la préparation de requête.

Il y a une nuance importante : échappement et préparation ne protègent pas de la même manière. L’échappement peut empêcher certains caractères de casser une chaîne SQL, mais si vous concaténez encore la logique (par exemple des morceaux entiers de clause WHERE, ORDER BY, ou des noms de https://gardewp.fr/securite-wordpress/ colonnes), vous risquez de rester vulnérable.

Donc, même si vous utilisez sanitize_text_field() pour des raisons “qualité de donnée”, gardez $wpdb->prepare() comme barrière anti-injection SQL.

Appliquer des validations “métier”, pas seulement “techniques”

Une requête préparée réduit énormément le risque, mais la robustesse ne s’arrête pas là. Un site bien défendu traite les entrées comme des objets à valider selon le contexte applicatif.

Prenons un cas courant : un paramètre status pour filtrer des enregistrements. Si vous laissez status libre et vous le mettez dans la requête comme un texte, vous ne vous rendez pas forcément vulnérable à l’injection SQL, surtout si c’est préparé. Mais vous pouvez vous retrouver avec des comportements inattendus, des charges inutiles et des résultats incohérents.

La validation métier consiste à limiter l’ensemble de valeurs acceptées. Concrètement, au lieu de “j’accepte n’importe quelle chaîne”, vous dites “je n’accepte que ces statuts”. Ce n’est pas une garantie anti-injection SQL, mais c’est une réduction de surface et une meilleure maîtrise du comportement.

Dans mon expérience, c’est souvent ce niveau qui fait la différence entre “ça passe en test” et “ça tient quand quelqu’un explore en profondeur”.

Cas particuliers : tri, colonnes dynamiques et “ORDER BY”

C’est souvent là que les développeurs se plantent. L’injection SQL ne vient pas uniquement de WHERE. Elle peut aussi venir du tri, des colonnes ou des expressions.

Exemple classique : vous laissez l’utilisateur décider du champ de tri :

// Risque si vous concaténez $orderby dans le SQL $order = isset($_GET['orderby']) ? $_GET['orderby'] : 'date'; $sql = "SELECT * FROM $wpdb->posts ORDER BY $order DESC";

Même si vous échappez des valeurs, ici vous changez la structure du SQL. Les placeholders ne fonctionnent pas comme un “remplacement magique de morceaux de syntaxe”.

La bonne approche consiste à whitelister les colonnes autorisées, puis à ne jamais injecter directement la valeur utilisateur dans une position syntaxique.

Un modèle prudent ressemble à celui-ci :

Vous listez les champs autorisés. Vous mappez le choix utilisateur sur une expression fixe. Vous gardez le reste en requêtes préparées.

C’est une bonne pratique en sécurité applicative, et elle se marie bien avec une logique de protection site WordPress, parce qu’elle rend le comportement prévisible.

Renforcer aussi en amont : nonce, capacités et contrôle d’accès

L’injection SQL parle à la base de données, mais la façon dont vous exposez l’entrée compte énormément. Même si votre requête est préparée, un endpoint trop ouvert peut être abusé pour :

provoquer des charges lourdes, exfiltrer des données autorisées, contourner des règles métier.

WordPress fournit des garde-fous que beaucoup oublient quand ils se concentrent sur le SQL. Un nonce ne protège pas l’injection SQL, mais il limite l’automatisation et les requêtes forgées. Les contrôles de capacités (current_user_can) évitent de donner accès à des données qui ne doivent pas l’être.

Dans un plugin, avant d’exécuter toute logique qui touche à la base, je préfère un ordre simple : contrôles d’accès, validation métier, puis requête préparée.

Cette séquence réduit aussi les risques “secondaires” que les gens ne relient pas toujours à l’injection SQL, comme la divulgation d’informations.

Diagnostiquer les vulnérabilités dans un plugin ou un thème

Quand vous auditez du code, cherchez moins “les mots” et plus les structures. L’injection SQL n’est pas seulement liée à la présence de $_GET et $_POST. Elle se cache dans les chemins où une entrée finit dans une chaîne SQL.

Voici un ensemble de vérifications rapides que j’utilise en audit interne. Ce n’est pas une garantie absolue, mais c’est efficace pour détecter les zones à inspecter :

Rechercher les concaténations autour de SELECT, UPDATE, DELETE ou de clauses WHERE et ORDER BY. Repérer les usages de $wpdbquery(), $wpdbget_results(), $wpdbget_var() avec des chaînes construites. Vérifier que les requêtes utilisent $wpdbprepare() avec des placeholders (%d, %s, etc.). Identifier les endpoints où l’entrée utilisateur arrive, puis remonter jusqu’à la construction de la requête. Noter les endroits où le code utilise des “morceaux de SQL” dynamiques, comme des colonnes ou des opérateurs.

Une règle de terrain : si vous voyez du SQL qui ressemble à une phrase construite avec des variables, vous devez ralentir et auditer. Les erreurs s’y trouvent souvent.

Exemple de correction réelle, avec des détails qui comptent

Imaginons un plugin qui enregistre une note associée à un identifiant d’article. Il reçoit post_id et note. Le développeur a fait un “concat” rapide :

$post_id = $_POST['post_id']; $note = $_POST['note']; $sql = "UPDATE $wpdbpostmeta SET meta_value = '$note' WHERE meta_key = 'my_note' AND post_id = $post_id"; $wpdbquery($sql);

Même si vous nettoyez note avec une fonction de texte, la concaténation reste un signal rouge. Et surtout, post_id est injecté en entier dans la clause WHERE.

Correction robuste :

$post_id = isset($_POST['post_id']) ? (int) $_POST['post_id'] : 0; $note = isset($_POST['note']) ? Wp_unslash($_POST['note']) : ''; $sql = $wpdbprepare( "UPDATE $wpdbpostmeta SET meta_value = %s WHERE meta_key = %s AND post_id = %d", $note, 'my_note', $post_id ); $wpdb->query($sql);

Ici, plusieurs points sont importants :

wp_unslash() si l’entrée vient de $_POST (WordPress ajoute souvent des slashes selon le contexte). Cast explicite de post_id en entier. Placeholder %s pour la valeur texte. Placeholder séparé pour meta_key.

Ce n’est pas juste “plus sécurisé”. C’est aussi plus clair pour la maintenance, et c’est souvent là que l’on gagne du temps après.

Réduire le risque avec une approche “défense en profondeur”

Limiter l’injection SQL au niveau du code est central, mais il existe aussi des couches de réduction de risque. Elles ne remplacent pas la correction du code, mais elles ajoutent des freins.

Par exemple, un WAF ou un pare-feu applicatif peut filtrer certaines formes de requêtes suspectes. Ce n’est pas une stratégie à elle seule, car un attaquant motivé peut varier le format. En revanche, si votre site est en production et que vous devez “gagner du temps” pendant une correction, ces couches peuvent réduire les essais automatisés.

Autre levier : la journalisation et la surveillance. Quand des requêtes SQL partent en erreur ou produisent des exceptions, vous voulez le voir. Une base de données qui “saute” sur des paramètres inattendus, c’est souvent un signal d’exploration.

Je préfère une logique pragmatique : code propre en premier, contrôle d’accès, puis durcissement périphérique et visibilité. C’est souvent plus efficace que de chercher une seule solution.

Focus sur les fonctions WordPress utiles, et leurs limites

WordPress fournit beaucoup d’API, et on pourrait croire que l’API “corrige” automatiquement les risques. En pratique, certaines fonctions aident, d’autres ne font qu’un nettoyage de surface.

Les requêtes SQL directes doivent rester préparées via $wpdb->prepare(). Les fonctions qui ne construisent pas de SQL, mais filtrent des données pour l’affichage, ne suffisent pas à elles seules pour l’injection SQL. Les protections côté affichage, comme esc_html, sont cruciales contre d’autres classes de vulnérabilité, mais elles ne sécurisent pas la base.

C’est un point de bon sens, mais il revient sans arrêt lors des revues. Les développeurs sécurisent le HTML, puis oublient le SQL.

Ce que je fais quand je dois corriger un site existant, sans tout réécrire

Réparer une faille dans un plugin tiers n’est pas toujours possible immédiatement. Parfois, vous corrigez votre code maison, mais vous ne contrôlez pas tout. Dans ce genre de situation, je privilégie une approche graduée, avec des décisions qui tiennent dans le temps.

Une option est de désactiver temporairement un endpoint ou un formulaire si vous identifiez un chemin d’entrée. Ensuite, vous corrigez la construction des requêtes et vous remettez en service.

Une autre option est de limiter l’accès aux actions concernées, par exemple en restreignant l’accès à des rôles spécifiques. Cela ne résout pas forcément une injection SQL “en soi”, mais ça réduit la probabilité d’exploitation.

Enfin, vous testez. Les tests ne doivent pas être uniquement “ça marche”. Ils doivent aussi confirmer que les entrées inattendues ne cassent pas la logique et ne déclenchent pas d’erreur SQL exploitable.

Test rapide des comportements à risque (sans chercher la faute volontaire)

Vous pouvez faire des tests de sécurité orientés “comportement” sans essayer de reproduire une attaque exacte. Le but est de voir si votre code réagit correctement aux entrées bizarres et aux paramètres manquants.

J’observe souvent :

erreurs visibles côté application (exceptions, messages de requête), différences nettes de résultats lorsque vous modifiez le format d’un paramètre, temps de réponse très différents sur des variations de filtres.

Si vous mettez temporairement le site dans un mode d’observabilité renforcé, vous pouvez détecter des requêtes anormales. Ensuite, vous corrigez au niveau du code.

Un point de prudence : ne laissez jamais un mode “debug” trop bavard en production. L’objectif, c’est de diagnostiquer, pas de publier les détails.

Les erreurs fréquentes qui reviennent, encore et encore

Sans faire de procès, il y a des patterns répétitifs. Je les ai vus à la fois sur du code interne et sur des extensions achetées. Voici les plus révélateurs :

Un développeur “protège” les données avec du nettoyage, mais laisse la concaténation SQL. 2) Une requête est préparée dans une partie, puis une autre clause redevient dynamique sans whitelist. 3) La validation n’est pas cohérente entre l’UI et l’endpoint, ce qui laisse passer des formats inattendus. 4) Le contrôle d’accès est absent sur des actions sensibles. 5) Le code gère un champ “par défaut”, puis oublie un autre chemin de paramètre.

Le plus important, c’est d’identifier ces patterns vite, et de réorienter l’effort vers la construction de requête.

Une checklist courte pour vos projets WordPress (pratique et réaliste)

Avant de valider un plugin ou une évolution qui touche à la base, j’utilise une vérification simple côté revue code. Elle vise à éviter les oublis typiques :

Toute requête SQL passe par $wpdb->prepare() ou une API qui ne construit pas de SQL à partir de concaténations. Les paramètres qui pilotent la syntaxe (tri, colonnes, opérateurs) sont whitelistes, jamais injectés tels quels. Les entrées utilisateur sont validées selon le contexte (types, plages, formats), même si la requête est préparée. Les endpoints contrôlent l’accès (nonce, capacités) avant toute opération. Les logs permettent de repérer les erreurs de requêtes et les comportements anormaux.

Si vous arrivez à appliquer ça de manière régulière, votre protection site WordPress contre l’injection SQL devient nettement plus solide, sans rendre le code ingérable.

Ce que vous pouvez exiger de votre équipe, concrètement

La sécurité n’est pas uniquement une affaire de techniques, c’est aussi une affaire de discipline. Dans un atelier de dev, je demande souvent deux choses :

D’abord, que le SQL soit considéré comme “non négociable” : toute modification doit être revue avec une attention particulière sur la construction des requêtes. Ensuite, que les endpoints aient une logique d’accès claire, parce qu’une requête sécurisée dans le SQL ne vaut rien si n’importe qui peut déclencher un traitement sensible.

Le bon ton de sécurité dans WordPress, c’est de rendre les chemins d’entrée visibles dans le code, et de tracer la chaîne “entrée utilisateur validation requête -> sortie”.

Conclusion implicite : réduire le risque, puis garder le contrôle

L’injection SQL n’est pas un monstre invisible. Elle est souvent la conséquence directe d’un choix de programmation : construire une requête avec des chaînes au lieu d’utiliser des paramètres préparés, et laisser des zones dynamiques sans whitelist. WordPress ne vous empêche pas de tomber dans le piège, mais il vous donne des outils, notamment via $wpdb->prepare() et le modèle d’API.

Une vraie protection site WordPress, en pratique, combine correction de code, contrôles d’accès, validation métier, et surveillance. C’est cette combinaison qui tient quand le site grossit, que les plugins s’enchaînent, et que les chemins d’entrée se multiplient.

Si vous voulez faire avancer les choses rapidement sur votre projet, commencez par l’audit des endroits où le code construit du SQL, puis verrouillez les endpoints qui reçoivent des paramètres. Une fois que ces deux axes sont traités, le reste devient plus simple.