Comment détecter les injections SQL dans votre code en 2026
Guide pratique pour identifier les requêtes SQL vulnérables en PHP, Node.js et Python — avant qu'un attaquant n'exploite votre base de données.
Les injections SQL restent l'une des vulnérabilités les plus exploitées au monde. En 2026, malgré les ORM et les frameworks modernes, des milliers d'applications en production restent exposées — souvent à cause d'une seule concaténation de chaîne oubliée.
Dans ce guide, vous apprendrez à reconnaître les patterns dangereux, à auditer votre codebase rapidement, et à intégrer la détection dans votre workflow quotidien.
Pourquoi les injections SQL persistent
Les ORM ne protègent pas automatiquement contre toutes les failles. Trois situations reviennent constamment :
- Requêtes brutes avec interpolation de variables utilisateur
- Tri et filtres dynamiques construits à partir de paramètres GET/POST
- Procédures stockées appelées avec des entrées non validées
Un attaquant n'a besoin que d'un seul point d'entrée pour exfiltrer des données, contourner l'authentification ou effacer des tables entières.
Patterns vulnérables à repérer
Concaténation directe (PHP, Node, Python)
// ❌ Dangereux
$query = "SELECT * FROM users WHERE email = '" . $_GET['email'] . "'";
// ❌ Dangereux — template literal non échappé
const sql = `SELECT * FROM orders WHERE id = ${req.params.id}`;
La correction passe par des requêtes préparées (prepared statements) ou un ORM qui paramètre systématiquement les valeurs.
ORDER BY et colonnes dynamiques
# ❌ Dangereux — le nom de colonne vient de l'utilisateur
cursor.execute(f"SELECT * FROM products ORDER BY {sort_column}")
Ici, un whitelist de colonnes autorisées est obligatoire. Aucun ORM ne peut deviner vos intentions.
Recherche full-text artisanale
Les champs de recherche sont une source classique de failles. Un LIKE '%' + input + '%' mal construit ouvre la porte aux injections aveugles et aux extractions par timing.
Méthode d'audit en 5 minutes
Avant de déployer, parcourez ces étapes :
- Grep votre codebase : cherchez
execute(,query(,raw(,mysqli_query, concaténations avec$ou+ - Tracez les entrées utilisateur : formulaires, API REST, webhooks, imports CSV
- Vérifiez les ORM :
Model.raw(),sequelize.query()sans bindings,text()SQLAlchemy - Testez localement avec des payloads OWASP (
' OR '1'='1,; DROP TABLE--) - Automatisez avec un scanner qui comprend le contexte de votre langage
Scanner en local avec Herozion
Herozion analyse votre projet entièrement en local — aucun fichier n'est envoyé au cloud. En moins de 8 secondes sur un dépôt moyen, il détecte :
- Concaténations SQL non paramétrées
- Appels ORM dangereux (
raw,unsafe) - Patterns OWASP A03 (Injection) dans 26 catégories
npm install -g herozion
herozion scan .
Les résultats s'affichent dans le terminal, dans VS Code/Cursor via l'extension, ou dans votre dashboard après un herozion push.
Bonnes pratiques à adopter dès aujourd'hui
Toujours paramétrer
Utilisez des placeholders (?, $1, :name) plutôt que la concaténation. Même pour les requêtes « simples ».
Valider les entrées structurelles
Les noms de colonnes, directions de tri (ASC/DESC) et opérateurs doivent passer par une liste blanche.
Intégrer au CI/CD
Ajoutez herozion scan . dans votre pipeline GitHub Actions. Bloquez les merges qui introduisent des failles critiques.
Former l'équipe
Une injection SQL est souvent le fruit d'une PR non relue. Documentez vos patterns sûrs et partagez les findings du scanner en revue de code.
Conclusion
Les injections SQL ne disparaîtront pas tant que du code legacy coexistera avec des microservices modernes. La bonne nouvelle : les détecter tôt coûte quelques secondes avec les bons outils.
Lancez un scan Herozion sur votre dépôt principal cette semaine. Vous saurez en moins de 10 secondes si une concaténation oubliée expose votre base de production.