Injection SQL : définition, exemples et prévention
L’injection SQL (SQLi) est une vulnérabilité qui permet à un attaquant d’insérer du code SQL malveillant dans une requête envoyée à la base de données. Classée parmi les risques critiques de l’OWASP Top 10, elle peut entraîner l’extraction complète des données, la modification de contenus ou la prise de contrôle du serveur.
Pentest web & API, audit IA, Toulouse, méthodologie OWASP/PTES
Comment fonctionne une injection SQL ?
' OR 1=1 --, il modifie la logique de la requête SQL pour contourner l’authentification ou extraire des données.Types d'injection SQL
- In-band (classique) : le résultat de l’injection est visible directement dans la réponse HTTP.
- Blind (aveugle) : pas de retour visible, l’attaquant déduit l’information via le temps de réponse ou des conditions booléennes.
- Out-of-band : exfiltration via un canal secondaire (DNS, HTTP vers un serveur contrôlé).
Impact pour une PME
Comment prévenir les injections SQL ?
- Utiliser des requêtes paramétrées (prepared statements) systématiquement.
- 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.
- Tester régulièrement avec un pentest incluant les vecteurs SQLi.
Exemple concret de SQLi
Un formulaire de login utilise la requête suivante côté serveur (PHP/Python) :
sql = "SELECT * FROM users WHERE email='" + email + "' AND pwd='" + pwd + "'"
Un attaquant saisit admin@x.com' -- dans le champ email. La requête devient :
SELECT * FROM users WHERE email='admin@x.com' -- ' AND pwd='...'
Le -- commente le reste. L'attaquant est authentifié comme admin sans connaître le mot de passe. Score CVSS typique : 9.1 (Critique).
Types d'injection SQL
In-band (classique) : la réponse SQL est renvoyée directement dans la page HTML — la plus facile à détecter.
Blind SQLi : l'application ne renvoie rien, mais le comportement (temps de réponse, présence d'un élément) dévoile la réponse — exploitable via sqlmap.
Out-of-band : exfiltration via DNS ou HTTP déclenchée par la base (INTO OUTFILE, xp_cmdshell) — plus rare mais dévastatrice.
Second-order : le payload est stocké en base puis exécuté lors d'une requête ultérieure — invisible dans les logs de formulaire.
FAQ Injection SQL
Les ORM (Prisma, Sequelize, Hibernate) protègent-ils automatiquement ?
À 95 %, oui. Le risque résiduel vient des $queryRaw, des WHERE construits à la main ou des fonctions de recherche full-text où le développeur concatène.
Un WAF peut-il bloquer toutes les SQLi ?
Non. Un WAF bloque les patterns évidents mais est contournable par encodage (URL, Unicode, commentaires MySQL /*!50000*/). Le code parametrisé reste la seule défense fiable.
Combien coûte une fuite de base clients pour une PME ?
Entre 50 000 € (PME < 50 employés) et 500 000 € (PME > 200 employés), selon IBM Cost of Data Breach 2025. Hors sanction CNIL et perte de clients.
Faut-il tester manuellement les SQLi ou automatiser ?
Les deux. sqlmap détecte les SQLi triviales ; un pentester manuel trouve les second-order et les blind conditionnées au contexte métier. Laucked combine les deux.
Besoin d'un pentest ?
Chez Laucked, nous testons vos applications web, API et intégrations sensibles avec une méthodologie OWASP/PTES. Diagnostic de surface gratuit, rapport sous 48-72h.
Demander un diagnostic gratuit