Comment les requêtes préparées empêchent-elles l'injection SQL ?
Réponse courte
Les requêtes préparées envoient d'abord le modèle de requête à la base de données, avec des emplacements réservés, afin que la structure soit figée avant l'arrivée de toute donnée utilisateur. Les paramètres sont ensuite liés comme de pures données et ne peuvent jamais être interprétés comme du SQL — ainsi une entrée comme ' OR 1=1 est traitée comme une chaîne littérale, pas comme du code. Cette séparation est le correctif canonique et fiable contre l'injection.
Les requêtes préparées (requêtes paramétrées) sont la défense canonique contre l'injection SQL car elles s'attaquent à la cause racine : l'injection SQL n'existe que parce que données et code voyagent ensemble dans une seule chaîne. Les requêtes préparées les séparent.
Comment fonctionne la séparation
La requête est envoyée à la base de données en deux phases :
- Préparation. L'application envoie le modèle de requête avec des emplacements réservés, par exemple
SELECT * FROM users WHERE email = ?. La base de données analyse, compile et planifie cette instruction avant de voir toute entrée utilisateur. La structure est désormais verrouillée. - Liaison et exécution. Les valeurs fournies par l'utilisateur sont envoyées séparément et liées aux emplacements réservés comme données typées. Elles ne sont jamais réanalysées comme du SQL.
Ainsi, si un attaquant soumet ' OR 1=1 --, la base de données traite toute cette chaîne comme une valeur littérale à comparer à la colonne email. Elle cherche un utilisateur dont l'email est littéralement ' OR 1=1 --, n'en trouve aucun et ne renvoie rien. La charge utile ne fait jamais partie de la logique de la requête.
Pourquoi l'échappement est l'alternative la plus faible
L'échappement manuel tente de neutraliser les caractères dangereux dans une chaîne concaténée — mais il est facile de se tromper (problèmes de jeu de caractères, contextes oubliés, champs numériques sans guillemets). Les requêtes préparées suppriment toute cette classe d'erreurs.
Où elles montrent leurs limites
Les emplacements réservés ne fonctionnent que pour les valeurs de données, pas pour les identifiants — vous ne pouvez pas paramétrer un nom de table, un nom de colonne ou une direction d'ORDER BY. Si ceux-ci doivent être dynamiques, vous devez utiliser une liste d'autorisation stricte associant l'entrée utilisateur à des identifiants connus et sûrs. Les ORM utilisent généralement des requêtes préparées en interne, mais les échappatoires en SQL brut peuvent réintroduire l'injection.
Les recruteurs recherchent l'explication « structure compilée avant l'arrivée des données », l'exemple concret de ' OR 1=1 devenant un littéral, et la conscience de la limite sur les identifiants nécessitant des listes d'autorisation.
Questions de suivi probables
- Pourquoi ne peut-on pas utiliser un emplacement réservé pour un nom de table ou de colonne ?
- Quel est le lien entre un ORM et les requêtes préparées ?
- Quand l'échappement ou la liste d'autorisation reste-t-il nécessaire ?