2.2 [Basics] Injections SQL : prévenir
Apprends les bases de la protection contre les injections SQL (SQLi) sans tarder !
Objectifs
- Savoir expliquer le danger d'une requête SQL dynamique dans un contexte de SQLi
- Savoir expliquer l'intérêt de l'utilisation des requêtes préparées (paramétrées) dans la prévention des SQLi
Après l'effort...

Source : Photo by Milos Darmanovic on Unsplash
[Rappel : À l'occasion de vacances que tu passes chez elle, ta mamie, une férue de cyber-sécurité plus connue sur les réseaux sous le nom de darkMereGrand_93, t'a tendu un piège qui t'a emmené·e au royaume des attaques par injections SQL.]
– Aussi agréables qu'un siège en simili cuir dans une salle d'attente bondée un jour de canicule, les SQLi ! conclut ta mamie en refermant son bureau, sa clef de sécurité USB autour du cou.
Le grille-pain tressaute tandis que vous êtes tous·tes les deux assis·es dans la cuisine. Enfin, la tartine chocolat-banane-beurre-confiture tant convoitée te tend les bras (et les miettes) !
– Et pourtant, ce n'est pas ce qu'il y a de plus difficile à dézinguer, comme failles, relance ta grand-mère, interceptant le pot de confiture entre le réfrigérateur et toi pour attirer ton attention.
Résigné·e, tu reposes lentement ta tartine sur la table.
– Oui, mamie..?
Des attaques relativement faciles à éviter
Ce n'est pas nous qui le disons, c'est l'OWASP : « Que tant d'attaques par injections de SQL réussissent est honteux, car il est EXTRÊMEMENT simple d'éviter les vulnérabilités aux injections SQL dans votre code ».
Mais si c'est si simple, pourquoi y a-t-il encore tant de vulnérabilités qui gambadent sur les internets ?
Une explication liée à la manière dont fonctionne l'industrie est proposée par ComputerWeekly (version archivée) :
SQL Injection attacks are so successful for a few reasons, the most common of which is that many newer developers simply don’t know about the problem. With project timelines being so short, these junior developers don’t have the time to research the security implications of using dynamic SQL. These applications then get left in production for months or years, with little to no maintenance. These developers can then move through their career without anyone giving them the guidance needed to prevent these problems.
Comme tu peux le constater ici, l'OWASP propose plusieurs stratégies de défense. Dans cette quête, nous ne parlerons que de la première : l'usage de requêtes préparées (prepared statements). Il s'agit du bouclier fondamental de protection contre les injections SQL (aussi appelées SQLi), et c'est ce qu'il faut connaître en priorité lorsqu'on est un·e développeur·euse débutant·e.
Liste des stratégies de défense contre les SQLi.
Le début de la partie « Why are SQL injection attacks so successful? » s'intéresse au manque de préparation des développeurs face aux SQLi.
Première ligne de défense
Utiliser des requêtes préparées
Si tes souvenirs sont encore frais, peut-être te rappelles-tu qu'une des pratiques à risques ouvrant la porte aux SQLi est l'utilisation de requêtes construites dynamiquement.
Exemple d'une requête dynamique : Un formulaire d'identification demande à un utilisateur son mot de passe. La valeur (= l'input) entrée par l'utilisateur est stockée dans une variable
password. La requête dynamique sera"SELECT * FROM Users WHERE userPassword = " + password)
Ce qui est dangereux, dans les requêtes construites dynamiquement, c'est l'absence d'encodage (on parle aussi d'échappement, escaping en anglais) de l'input transmis par l'utilisateur. En effet, l'encodage est un travail de conversion qui permet à la machine d'interpréter l'input comme une donnée, et non comme un code à exécuter.
Les requêtes préparées (aussi appelées requêtes paramétrées, ou parameterized statements, en anglais) permettent d'éviter cette construction dynamique. Chaque langage / techno dispose d'une façon d'effectuer des requêtes préparées. Découvrir / réviser le concept ici : https://www.securityjourney.com/post/how-to-prevent-sql-injection-vulnerabilities-how-prepared-statements-work
Et pour comprendre comment les requêtes préparées permettent d'interpréter l'input de l'utilisateur comme une donnée et non du SQL, vas voir cette réponse très instructive donnée sur StackOverflow.
Les requêtes préparées sont disponibles dans la plupart des technologies touchant au SQL. À toi de trouver comment elles doivent être mises en place dans les projets que tu gères.
Utiliser un ORM
Les ORM (Object Relational Mapping) sont – dit simplement – des programmes qui facilitent la communication entre ton application web et la base de données de celle-ci. Utilisant par défaut des requêtes paramétrées, elles facilitent le travail des développeurs·euses, qui n'ont plus besoin d'écrire leurs requêtes à la main... de quoi réduire la tentation de faire des requêtes SQL dynamiques.
https://www.linkedin.com/advice/3/what-advantages-disadvantages-using-orm
Exemple avec Sequelize JS : https://medium.com/@DanielAlvesOmnes/preventing-sql-injection-with-sequelize-6318c32eb3de
Pour aller plus loin, blinder au delà de ce que fait l'ORM
Une explication claire et détaillée de la manière dont les requêtes paramétrées permettent d'éviter les attaques par SQLi.