Protéger sa base WordPress contre les injections SQL : guide 2026

Qu’est-ce qu’une injection SQL en 2026 ?

Une injection SQL consiste à insérer du code SQL malveillant dans un paramètre attendu par l’application — formulaire, URL, header HTTP, cookie. Si l’application concatène ce paramètre dans une requête sans l’échapper, l’attaquant exécute ses propres commandes sur la base.

Exemple simplifié : un formulaire de recherche envoie?q=chien. Si le code PHP fait :

$sql = "SELECT * FROM wp_posts WHERE title LIKE '%" . $_GET['q'] . "%'";

Un attaquant envoyant ?q=%' UNION SELECT user_pass FROM wp_users--récupère les hashes de mots de passe.

Pourquoi WordPress est-il particulièrement exposé ?

• Écosystème de plugins tiers : 60 000+ plugins sur WordPress.org, dont une longue traîne de plugins mal maintenus
• Concentration des données : WP_users, WP_usermeta, WP_options stockent les identités, jetons et secrets
• Hébergement mutualisé : une compromission expose parfois toutes les bases voisines

Les 5 vecteurs principaux en 2026

1. Plugins avec endpoints AJAX mal échappés

La plupart des CVE WordPress 2024–2026 portent sur des endpointsadmin-ajax.php ou des routes REST API custom. Toujours utiliser $wpdb->prepare().

2. Thèmes premium piratés (nulled)

Les versions « nulled » de thèmes payants distribuées sur des forums contiennent fréquemment des backdoors qui exfiltrent les bases via SQL.

3. shortcodes acceptant des attributs SQL

Certains plugins exposent des shortcodes qui construisent des requêtes SQL avec des attributs utilisateur. Si un auteur compromis publie un article, il peut exploiter ces shortcodes.

4. Imports CSV/Excel

Les plugins d’import (WP All Import, etc.) traitent des fichiers fournis par l’utilisateur. Un CSV malicieusement formé peut déclencher des injections lors du parsing.

5. Champs personnalisés exposés en API

Les meta-fields exposés via l’API REST (par exemple via ACF) peuvent être vecteurs si une recherche full-text mal échappée est implémentée.

La défense en profondeur

Aucun outil seul ne suffit. La bonne stratégie combine plusieurs couches.

Couche 1 — Le code (idéal mais hors de portée)

Toujours utiliser $wpdb->prepare(), valider et typer les entrées. En théorie. En pratique, vous ne contrôlez pas le code des 30 plugins que vous utilisez.

Couche 2 — Le WAF applicatif

Wordfence, Sucuri, ou un WAF en amont (Cloudflare, ModSecurity) détectent et bloquent les patterns d’injection avant qu’ils n’atteignent PHP. Très efficace, mais pas infaillible : les attaquants ajustent leurs payloads pour contourner les règles.

Couche 3 — L’audit et la mise à jour

Tenir un inventaire des plugins, suivre les CVE, mettre à jour dans la semaine. Désinstaller (pas seulement désactiver) les plugins non utilisés.

Couche 4 — Le chiffrement E2E des données sensibles

C’est la couche que la plupart des sites WordPress oublient. Si un attaquant parvient à exfiltrer wp_users malgré les autres défenses, il récupère du contenu chiffré au lieu de données en clair. C’est exactement le rôle de WPSQL : chiffrer les tables sensibles au repos avec des clés que Secufor ne possède pas.

Que faire si on est compromis ?

1. Couper l’accès public (mode maintenance)
2. Faire un snapshot de la base pour analyse forensique
3. Réinitialiser tous les mots de passe et clés d’API
4. Forcer la déconnexion de tous les utilisateurs
5. Notifier la CNIL sous 72 h si des données personnelles sont concernées
6. Faire intervenir un expert pour identifier le vecteur et la rémanence