Fiche de révision — Injections SQL
Mise à jour le 6 août 2026
Le problème : concaténer au lieu de paramétrer
-- Vulnérable : la valeur est concaténée dans le texte SQL
SELECT * FROM utilisateurs WHERE identifiant = '${identifiant}'La protection : une requête préparée
-- Sûr : la valeur est transmise à part, jamais interprétée comme du SQL
SELECT * FROM utilisateurs WHERE identifiant = ?💡 Astuce
Une requête préparée neutralise ' OR '1'='1 aussi bien que UNION SELECT : la base de données traite toujours la valeur fournie comme une donnée brute, jamais comme une instruction.
L'essentiel
Pourquoi une requête SQL construite par concaténation est-elle dangereuse ?
Parce qu'elle mélange le code SQL écrit par le développeur et les données fournies par l'utilisateur : rien ne distingue plus une donnée d'une instruction SQL aux yeux du moteur de base de données.
Que produit la valeur ' OR '1'='1 insérée dans un mot de passe concaténé ?
Une condition WHERE toujours vraie : '1'='1' l'est systématiquement, donc la requête retourne un utilisateur sans que le bon mot de passe ait été fourni.
À quoi sert un commentaire SQL (--) dans une charge d'injection ?
À ignorer le reste de la requête d'origine, y compris une seconde condition qui suivrait la vérification du mot de passe.
Que doit vérifier une injection UNION SELECT pour fonctionner ?
Retourner le même nombre de colonnes que la requête d'origine, avec des types compatibles.
Comment déterminer le nombre de colonnes d'une requête à l'aveugle ?
En incrémentant un ORDER BY jusqu'à provoquer une erreur : une erreur sur ORDER BY N indique que la requête retourne N-1 colonnes.
Quelle est la protection efficace contre les injections SQL ?
Les requêtes préparées (paramétrées) : la valeur est transmise séparément du texte SQL, jamais concaténée dans la requête elle-même.