L’injection SQL : une menace toujours d’actualité

En 2024, l’injection SQL figure encore dans le Top 3 des vulnérabilités les plus exploitées selon le classement OWASP (Open Web Application Security Project). Malgré des décennies de sensibilisation, cette faille continue de faire des ravages : selon un rapport de Imperva, les attaques par injection SQL représentent environ 33 % de l’ensemble des attaques ciblant les applications web.

Le principe est redoutablement simple. Un attaquant insère du code SQL malveillant dans un champ de saisie — formulaire de connexion, barre de recherche, URL — pour détourner les requêtes envoyées à votre base de données. Les conséquences peuvent être catastrophiques :

  • Vol de données sensibles (identifiants, emails, coordonnées bancaires)
  • Modification ou suppression de contenus en base de données
  • Prise de contrôle complète du serveur dans les cas les plus graves
  • Atteinte à la réputation et sanctions RGPD pouvant atteindre 4 % du chiffre d’affaires annuel

Que vous gériez un site e-commerce sous PrestaShop, un site vitrine WordPress ou une application web sur mesure, comprendre et prévenir l’injection SQL n’est pas une option : c’est une nécessité absolue.

Comment fonctionne une injection SQL

Le mécanisme de base

Pour bien se protéger, il faut d’abord comprendre comment l’attaque fonctionne. Prenons un exemple concret. Imaginez un formulaire de connexion dont le code backend ressemble à ceci :

SELECT * FROM utilisateurs WHERE login = 'jean' AND mot_de_passe = 'monMotDePasse123';

Cette requête est construite dynamiquement à partir des valeurs saisies par l’utilisateur. Jusqu’ici, tout va bien. Mais que se passe-t-il si, au lieu d’un vrai identifiant, l’attaquant saisit ceci dans le champ login ?

' OR '1'='1' --

La requête SQL devient alors :

SELECT * FROM utilisateurs WHERE login = '' OR '1'='1' --' AND mot_de_passe = '';

Le double tiret -- commente la fin de la requête. La condition '1'='1' est toujours vraie. Résultat : l’attaquant accède au premier compte de la base de données, souvent celui de l’administrateur.

Les différents types d’injection SQL

L’injection SQL ne se limite pas à ce scénario simpliste. Elle se décline en plusieurs variantes, chacune avec son niveau de dangerosité :

Type d’injectionPrincipeDangerositéDétection
In-band (classique)L’attaquant utilise le même canal pour injecter et récupérer les donnéesÉlevéeFacile
Blind (à l’aveugle)Pas de retour direct ; l’attaquant déduit les informations via des réponses vrai/faux ou des délaisÉlevéeDifficile
Out-of-bandLes données sont exfiltrées via un canal différent (DNS, HTTP externe)Très élevéeTrès difficile
Second orderLe code malveillant est stocké puis exécuté ultérieurement dans une autre requêteTrès élevéeTrès difficile

Les injections “blind” et “second order” sont particulièrement redoutables car elles passent sous le radar de nombreux outils de détection basiques.

Les cibles les plus fréquentes

Sites e-commerce et applications transactionnelles

Les boutiques en ligne sont des cibles privilégiées. Elles stockent des données clients, historiques de commandes, informations de paiement et parfois des tokens d’authentification. Un site PrestaShop ou WooCommerce mal sécurisé peut exposer des milliers de fiches clients en une seule attaque.

En 2023, une vulnérabilité critique d’injection SQL a été découverte dans un module PrestaShop très populaire, affectant potentiellement plus de 300 000 boutiques en ligne. Chez Lueur Externe, agence certifiée PrestaShop, nous avions alerté nos clients et déployé les correctifs en moins de 24 heures.

Formulaires de contact et espaces membres

Tout formulaire qui interagit avec une base de données est une porte d’entrée potentielle :

  • Formulaires de connexion et d’inscription
  • Barres de recherche interne
  • Formulaires de contact avec stockage en base
  • Filtres de catalogue produit
  • Pages de profil utilisateur

API et services web

Avec la montée en puissance des architectures headless et des API REST/GraphQL, les points d’entrée se multiplient. Une API mal protégée peut exposer l’intégralité de votre base de données sans que l’interface front-end ne montre le moindre signe d’anomalie.

Les bonnes pratiques pour se protéger

1. Utiliser systématiquement les requêtes préparées

C’est LA mesure de protection la plus efficace contre l’injection SQL. Les requêtes préparées (ou requêtes paramétrées) séparent strictement le code SQL des données utilisateur. La base de données sait alors exactement ce qui est une instruction et ce qui est une valeur.

Voici la différence entre une requête vulnérable et une requête préparée en PHP avec PDO :

// ❌ VULNÉRABLE : concaténation directe
$query = "SELECT * FROM utilisateurs WHERE login = '" . $_POST['login'] . "'";
$result = $pdo->query($query);

// ✅ SÉCURISÉ : requête préparée avec PDO
$stmt = $pdo->prepare("SELECT * FROM utilisateurs WHERE login = :login");
$stmt->bindParam(':login', $_POST['login'], PDO::PARAM_STR);
$stmt->execute();
$result = $stmt->fetchAll();

Avec la requête préparée, même si l’utilisateur saisit ' OR '1'='1' --, la valeur sera traitée comme une simple chaîne de caractères et non comme du code SQL exécutable.

Règle absolue : ne jamais construire une requête SQL par concaténation de chaînes avec des données provenant de l’utilisateur. Jamais.

2. Valider et assainir toutes les entrées utilisateur

La validation des entrées constitue une deuxième ligne de défense indispensable :

  • Validation de type : un champ numérique ne doit accepter que des chiffres
  • Validation de longueur : limiter le nombre de caractères acceptés
  • Liste blanche : n’accepter que les valeurs prévues (pour les menus déroulants, les filtres, etc.)
  • Échappement : transformer les caractères spéciaux SQL (', ", \, ;) en séquences inoffensives
// Validation d'un identifiant numérique
$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);
if ($id === false || $id === null) {
    die('Identifiant invalide');
}

// Assainissement d'une chaîne
$recherche = filter_input(INPUT_GET, 'q', FILTER_SANITIZE_SPECIAL_CHARS);

3. Appliquer le principe du moindre privilège

Votre application web n’a probablement pas besoin d’un accès administrateur à la base de données. Configurez des comptes de base de données dédiés avec des droits restreints :

  • Le compte utilisé par le site ne doit avoir que les droits SELECT, INSERT, UPDATE sur les tables nécessaires
  • Les droits DROP, ALTER, CREATE ne doivent jamais être accordés au compte applicatif
  • Utilisez des comptes séparés pour la lecture et l’écriture si possible
  • Supprimez les bases de données de test et les comptes par défaut

Ainsi, même en cas d’injection réussie, l’attaquant ne pourra pas supprimer des tables ou modifier la structure de la base.

4. Déployer un Web Application Firewall (WAF)

Un WAF analyse le trafic HTTP en temps réel et bloque les requêtes suspectes avant qu’elles n’atteignent votre application. Les solutions les plus efficaces incluent :

  • AWS WAF : idéal pour les infrastructures hébergées sur Amazon Web Services (une spécialité de Lueur Externe, certifiée AWS Solutions Architect)
  • Cloudflare WAF : solution SaaS accessible et performante
  • ModSecurity : module open source pour Apache et Nginx

Un WAF ne remplace pas les bonnes pratiques de développement, mais il ajoute une couche de protection supplémentaire capable de bloquer les attaques connues et les variantes émergentes.

5. Mettre à jour et auditer régulièrement

La sécurité n’est pas un état mais un processus continu :

  • Mettez à jour votre CMS, vos plugins, modules et frameworks dès que des correctifs de sécurité sont publiés
  • Auditez votre code régulièrement, en particulier les modules tiers et les développements personnalisés
  • Effectuez des tests de pénétration (pentests) pour identifier les vulnérabilités avant les attaquants
  • Surveillez les logs de votre base de données pour détecter les requêtes anormales

Cas pratique : sécuriser un site WordPress

WordPress alimente plus de 43 % des sites web mondiaux en 2024. Cette popularité en fait une cible de choix. Voici un plan de sécurisation spécifique contre les injections SQL :

Utiliser la classe wpdb correctement

WordPress fournit la méthode $wpdb->prepare() qui fonctionne exactement comme une requête préparée :

// ❌ VULNÉRABLE
global $wpdb;
$results = $wpdb->get_results(
    "SELECT * FROM wp_posts WHERE post_title LIKE '%" . $_GET['s'] . "%'"
);

// ✅ SÉCURISÉ
global $wpdb;
$search = '%' . $wpdb->esc_like($_GET['s']) . '%';
$results = $wpdb->get_results(
    $wpdb->prepare("SELECT * FROM wp_posts WHERE post_title LIKE %s", $search)
);

Vérifier les plugins installés

Selon WPScan, plus de 90 % des vulnérabilités WordPress proviennent des plugins et thèmes, pas du cœur du CMS. Pour chaque plugin :

  • Vérifiez la date de dernière mise à jour (méfiance au-delà de 6 mois sans mise à jour)
  • Consultez la base de données WPScan Vulnerability Database
  • Privilégiez les plugins avec un grand nombre d’installations actives et des avis positifs
  • Supprimez les plugins inactifs (un plugin désactivé reste un vecteur d’attaque)

Renforcer la configuration serveur

  • Changez le préfixe des tables WordPress (remplacez wp_ par un préfixe personnalisé)
  • Désactivez l’édition de fichiers depuis l’admin (define('DISALLOW_FILE_EDIT', true);)
  • Restreignez l’accès à wp-admin par IP si possible
  • Activez les en-têtes de sécurité HTTP (Content-Security-Policy, X-Content-Type-Options, etc.)

Cas pratique : sécuriser un site PrestaShop

PrestaShop utilise nativement Doctrine DBAL et PDO pour interagir avec la base de données, ce qui offre une bonne protection de base. Cependant, plusieurs points de vigilance subsistent :

  • Les modules tiers restent le maillon faible. Certains développeurs utilisent encore des requêtes SQL construites par concaténation
  • Utilisez systématiquement les méthodes pSQL() et (int) pour échapper les variables dans les requêtes
  • Activez le mode SSL sur l’ensemble du back-office et du front-office
  • Mettez en place une politique de mise à jour stricte pour tous les modules installés
// Échappement PrestaShop natif
$name = pSQL(Tools::getValue('name'));
$id = (int) Tools::getValue('id_product');

Les outils pour tester la vulnérabilité de votre site

Avant d’attendre qu’un attaquant découvre vos failles, testez-les vous-même (ou faites-les tester par un professionnel). Voici les outils les plus reconnus :

  • SQLMap : outil open source de référence pour détecter et exploiter les injections SQL (usage éthique uniquement)
  • OWASP ZAP : scanner de vulnérabilités web gratuit et complet
  • Burp Suite : outil professionnel d’audit de sécurité web
  • Acunetix : scanner commercial avec détection automatisée des injections SQL
  • WPScan : scanner spécialisé WordPress

⚠️ Important : n’utilisez ces outils que sur vos propres sites ou avec une autorisation écrite explicite. Scanner un site tiers sans permission est illégal.

Les erreurs à ne surtout pas commettre

Même avec de bonnes intentions, certaines pratiques courantes offrent une fausse sensation de sécurité :

  1. Se fier uniquement à la validation côté client (JavaScript) : un attaquant contourne le JavaScript en quelques secondes. La validation doit toujours être dupliquée côté serveur.

  2. Croire que les ORM protègent automatiquement : les ORM comme Doctrine ou Eloquent protègent bien contre l’injection SQL… tant que vous utilisez leurs méthodes correctement. Dès que vous injectez du SQL brut (raw queries), le risque revient.

  3. Masquer les messages d’erreur sans les corriger : cacher les erreurs SQL à l’utilisateur est bien, mais cela ne corrige pas la faille sous-jacente. L’attaquant utilisera des techniques blind pour contourner l’absence de messages.

  4. Négliger les sauvegardes : si le pire arrive, une sauvegarde récente et testée de votre base de données est votre ultime filet de sécurité. Sauvegardez quotidiennement et testez la restauration au moins une fois par trimestre.

  5. Penser que son site est “trop petit” pour être attaqué : les attaques par injection SQL sont massivement automatisées. Des bots scannent en permanence des millions de sites sans distinction de taille. Votre boutique en ligne de 50 produits est autant ciblée qu’un géant du e-commerce.

Checklist de sécurité anti-injection SQL

Voici un récapitulatif des mesures à mettre en place, classées par priorité :

  • ✅ Utiliser des requêtes préparées pour 100 % des interactions avec la base de données
  • ✅ Valider et assainir toutes les entrées utilisateur côté serveur
  • ✅ Appliquer le principe du moindre privilège sur les comptes de base de données
  • ✅ Mettre à jour le CMS, les plugins, les modules et le framework régulièrement
  • ✅ Déployer un WAF (Web Application Firewall)
  • ✅ Désactiver l’affichage des erreurs SQL en production
  • ✅ Chiffrer les données sensibles stockées en base (mots de passe hashés, données personnelles chiffrées)
  • ✅ Effectuer des tests de pénétration au moins deux fois par an
  • ✅ Maintenir des sauvegardes automatiques et testées
  • ✅ Former les développeurs aux bonnes pratiques de sécurité OWASP

Conclusion : la sécurité est un investissement, pas une dépense

L’injection SQL est une faille ancienne, bien documentée, et pourtant elle continue de figurer en tête des classements de vulnérabilités web année après année. La raison est simple : trop de sites sont construits ou maintenus sans véritable stratégie de sécurité.

Le coût d’une attaque réussie — perte de données, atteinte à la réputation, sanctions RGPD, interruption d’activité — dépasse systématiquement et de très loin le coût de la prévention. Protéger ses bases de données contre les injections SQL n’est pas un luxe technique réservé aux grandes entreprises : c’est une obligation pour tout site professionnel.

Chez Lueur Externe, nous accompagnons depuis 2003 les entreprises des Alpes-Maritimes et au-delà dans la sécurisation de leurs sites web et applications. Experts certifiés PrestaShop et AWS Solutions Architect, nous réalisons des audits de sécurité complets, mettons en place des architectures robustes et formons vos équipes aux bonnes pratiques.

Votre site est-il réellement protégé contre les injections SQL ? Ne laissez pas le doute subsister. Contactez les experts Lueur Externe pour un audit de sécurité personnalisé et dormez sur vos deux oreilles.