Prévention de l'Injection SQL : le Guide du Développeur (2026)

Qu'est-ce que la prévention de l'injection SQL ?

La prévention de l'injection SQL est l'ensemble des pratiques de code et de configuration qui empêchent une entrée contrôlée par un attaquant de modifier le sens d'une requête de base de données. L'idée centrale est la séparation : la commande SQL est fixée par le développeur, et toute valeur fournie par l'utilisateur voyage à côté d'elle comme de simples données que le moteur n'interprète jamais comme des instructions.

Cette séparation, c'est tout le jeu. Une application vulnérable traite la requête comme une grande chaîne qu'elle assemble à l'exécution, donc un attaquant qui contrôle une partie de la chaîne contrôle une partie de la commande. Une application défendue remet à la base de données un modèle de requête et un sac de valeurs, et la base de données les garde séparés, quels que soient les caractères contenus dans les valeurs.

L'injection SQL correspond à CWE-89, et ses correctifs sont exceptionnellement bien établis. Il n'y a aucun framework astucieux ni produit payant dont vous ayez besoin. La défense principale est une fonctionnalité de langage présente dans chaque pilote de base de données courant depuis vingt ans, et la plupart des SQLi observées n'existent que parce que quelqu'un a concaténé une chaîne au lieu de l'utiliser.

Pourquoi l'injection SQL se produit : la cause racine

Toute injection SQL a la même origine : l'application construit une requête en concaténant l'entrée utilisateur dans le texte SQL. Dès cet instant, la frontière entre code et données a disparu, et la base de données interprète ce que l'utilisateur a envoyé comme une partie de la commande.

Voici l'erreur classique, écrite telle qu'elle apparaît encore dans de vraies bases de code :

// Vulnérable : l'entrée est concaténée directement dans la requête
query = "SELECT * FROM users WHERE username = '" + name + "'";

Si name vaut alice, la requête se comporte bien. Si name vaut ' OR '1'='1, la requête devient SELECT * FROM users WHERE username = '' OR '1'='1', ce qui est vrai pour chaque ligne. L'entrée a cessé d'être un nom d'utilisateur pour devenir de la logique. Rien dans la chaîne n'indique à la base de données que l'apostrophe de l'attaquant était censée être une donnée.

C'est pourquoi la liste noire de caractères échoue en tant que stratégie. Les équipes tentent de retirer les apostrophes ou d'interdire le mot UNION, et les attaquants contournent avec l'encodage, les commentaires, les astuces de casse, ou une syntaxe propre à la base de données. Vous ne pouvez pas énumérer chaque entrée dangereuse, car le problème n'est pas l'entrée, c'est la concaténation. Corrigez le mécanisme et vous cessez de vous soucier des charges utiles.

Les requêtes paramétrées : la défense principale

Quelle est la meilleure façon de prévenir l'injection SQL ? Utilisez des requêtes paramétrées, aussi appelées instructions préparées. Vous écrivez le SQL avec des marqueurs à l'emplacement des valeurs, puis vous passez les valeurs séparément. Le pilote envoie d'abord la structure de la requête à la base de données, si bien que lorsque les valeurs arrivent, elles ne peuvent jamais être que des données. Les apostrophes et mots-clés d'un attaquant sont stockés comme une chaîne littérale, jamais interprétés comme du SQL.

L'aide-mémoire OWASP sur la prévention de l'injection SQL place cela en première position et comme défense la plus forte, et cela fonctionne de la même manière dans chaque environnement. La syntaxe change, le principe non.

PHP (PDO)

$stmt = $pdo->prepare('SELECT * FROM users WHERE username = ?');
$stmt->execute([$name]);
$user = $stmt->fetch();

Python (psycopg2 / sqlite3)

cur.execute("SELECT * FROM users WHERE username = %s", (name,))
user = cur.fetchone()

Notez la virgule finale : le second argument est un tuple de paramètres, pas du formatage de chaîne. N'utilisez jamais f"...{name}" ni % pour construire le SQL, c'est de la concaténation déguisée.

Java (PreparedStatement)

PreparedStatement ps = conn.prepareStatement(
    "SELECT * FROM users WHERE username = ?");
ps.setString(1, name);
ResultSet rs = ps.executeQuery();

Node.js (mysql2 / pg)

const [rows] = await conn.execute(
  'SELECT * FROM users WHERE username = ?', [name]);

Dans chaque exemple, le texte de la requête est une constante écrite par le développeur, et name arrive par un argument séparé. Passez ' OR '1'='1 à n'importe lequel d'entre eux et la base de données cherche un utilisateur littéralement nommé ' OR '1'='1, n'en trouve aucun, et ne renvoie rien. L'attaque n'a nulle part où atterrir.

Les mappeurs objet-relationnel comme Hibernate, Entity Framework, SQLAlchemy et l'ORM de Django paramètrent par défaut, ce qui explique en grande partie pourquoi ils sont plus sûrs que le SQL écrit à la main. Le piège est la porte de sortie : les méthodes de requête brute et les clauses WHERE construites par chaîne à l'intérieur d'un ORM sont tout aussi injectables que n'importe quelle autre concaténation. Lors de tests sur de vraies applications, ce sont les bases de code très orientées ORM où je regarde le plus attentivement la seule requête brute que quelqu'un a écrite pour un rapport que l'ORM ne savait pas exprimer.

Validation des entrées et liste d'autorisation

La paramétrisation couvre les valeurs. Elle ne peut pas couvrir les parties d'une requête qui ne sont pas des valeurs : noms de tables, noms de colonnes, et la direction d'un ORDER BY. Vous ne pouvez pas lier un nom de colonne comme paramètre, donc si un utilisateur peut choisir une colonne de tri ou une table, il vous faut un autre contrôle.

Ce contrôle est la validation par liste d'autorisation. Comparez l'entrée à un ensemble fixe d'options connues comme valides et rejetez tout le reste, plutôt que d'essayer d'assainir ce qui est arrivé.

# Sûr : l'utilisateur choisit une clé, le serveur possède l'identifiant SQL
ALLOWED_SORT = {"name": "username", "date": "created_at"}
column = ALLOWED_SORT.get(user_choice, "username")
cur.execute(f"SELECT * FROM users ORDER BY {column}")

L'utilisateur ne fournit jamais le nom de la colonne. Il fournit une étiquette, et le serveur la relie à un identifiant codé en dur auquel il fait déjà confiance. La f-string n'est sûre ici que parce que column ne peut jamais être autre chose qu'une valeur écrite par le développeur.

La validation par liste d'autorisation est une défense d'appoint, pas un remplacement des requêtes paramétrées. Utilisez-la pour les identifiants et la structure, utilisez les paramètres pour chaque valeur, et traitez toute entrée qui échoue à la validation comme une demande à rejeter, non à nettoyer. Les vérifications de type aident aussi : si un identifiant doit être un entier, convertissez-le et laissez une mauvaise valeur échouer bruyamment.

Moindre privilège et défense en profondeur

Les requêtes paramétrées arrêtent l'injection au niveau du code. Les contrôles ci-dessous limitent les dégâts si une requête passe malgré tout, et ce sont eux qui transforment une potentielle fuite en un incident contenu. Superposez-les, car aucun contrôle unique ne devrait être la seule chose entre un attaquant et vos données.

• Comptes de base de données à moindre privilège. Le compte avec lequel votre application web se connecte ne devrait détenir que les droits dont il a besoin. Un point d'accès en lecture n'a pas besoin de DELETE, DROP, ni d'accès à d'autres schémas. Si une injection atterrit malgré tout, un compte verrouillé limite ce qu'elle peut atteindre.
• Comptes séparés par fonction. Ne faites pas transiter l'ensemble de l'application, les migrations et l'outillage d'administration par un même utilisateur tout-puissant. Séparez-les pour qu'une faille dans un chemin ne puisse pas réécrire toute la base de données.
• Gestion sûre des erreurs. Ne renvoyez jamais les erreurs brutes de la base de données au client. Les messages verbeux offrent à un attaquant les noms de tables, les types de colonnes et la forme de la requête qui transforment une devinette à l'aveugle en une attaque rapide et ciblée. Enregistrez le détail côté serveur et affichez un message générique à l'utilisateur.
• Procédures stockées, utilisées correctement. Une procédure stockée n'est sûre que si elle utilise des paramètres en interne. Une procédure qui concatène ses propres arguments dans du SQL dynamique est exactement aussi vulnérable que du code en ligne, donc la sécurité vient de la paramétrisation, pas de la procédure elle-même.
• Un WAF comme filet de sécurité, pas comme correctif. Un pare-feu applicatif web peut filtrer les schémas d'injection évidents et gagner du temps face aux scans automatisés, mais c'est un ralentisseur posé au-dessus des vrais correctifs. Ne laissez jamais un WAF être la raison pour laquelle une requête concaténée reste dans la base de code.

En pratique, le moindre privilège est le contrôle que les équipes ignorent le plus souvent parce que l'application « marche » avec un compte superutilisateur. Elle marche jusqu'au moment où une injection transforme ce superutilisateur en compte de l'attaquant, et à cet instant la différence entre un accès SELECT seul et le contrôle total est la différence entre une anomalie journalisée et un gros titre.

Comment tester vos défenses contre l'injection SQL

Comment savoir si votre prévention fonctionne vraiment ? Attaquez votre propre code. Envoyez les charges utiles qu'un attaquant enverrait, dans un lab ou un environnement de test autorisé, et confirmez que la requête les traite comme des données inertes. Une défense que vous n'avez jamais essayé de casser est une défense dont vous espérez seulement la présence.

Une routine concrète ressemble à ceci :

• Sondez d'abord manuellement. Glissez une simple apostrophe, puis ' OR '1'='1, puis un UNION SELECT dans chaque entrée qui atteint une requête. Sur un point d'accès paramétré, vous obtenez un résultat vide ou un « non trouvé » propre, jamais une erreur de base de données ni des lignes supplémentaires.
• Lancez un scanner automatisé. Un outil comme sqlmap martèlera les paramètres avec des centaines de variantes bien plus vite que vous à la main. Ne le pointez que vers des systèmes que vous possédez ou êtes autorisé à tester.
• Relisez le code, pas seulement les réponses. Cherchez la concaténation de chaînes près des appels de requête et les portes de sortie SQL brutes dans votre ORM. La plupart des SQLi sautent aux yeux dans le code source une fois que vous connaissez le motif à repérer.
• Testez les identifiants, pas seulement les valeurs. Les paramètres de tri, les champs de filtre et tout ce qui atterrit dans une position de colonne ou de table sont les endroits que la paramétrisation ne couvre pas. Confirmez que ceux-là passent par une liste d'autorisation.

L'intérêt de tester vos propres défenses est que cela forge l'instinct de repérer la faille lors d'une relecture de code, là où la prévention coûte le moins cher. Apprendre à exploiter SQLi et apprendre à le prévenir sont la même compétence vue de deux côtés, et faire la moitié offensive dans un lab contrôlé est le moyen le plus rapide d'intérioriser la moitié défensive.

Liste de contrôle pour la prévention de l'injection SQL

Une liste courte et ordonnée que vous pouvez appliquer à n'importe quelle base de code. Si le premier point est solide partout, le reste n'est que du renforcement.

1. Utilisez des requêtes paramétrées pour chaque valeur. Aucune entrée utilisateur n'est jamais concaténée dans le texte SQL. C'est le correctif qui met fin à la vulnérabilité.
2. Mettez en liste d'autorisation tout ce que vous ne pouvez pas paramétrer. Noms de tables, noms de colonnes et directions de tri se relient à un ensemble fixe de valeurs possédées par le serveur.
3. Préférez un ORM, mais auditez ses requêtes brutes. Les méthodes ORM par défaut paramètrent ; la porte de sortie SQL brute ne se surveille pas toute seule.
4. Faites tourner l'application avec un compte de base de données à moindre privilège. N'accordez que les opérations dont le code a réellement besoin.
5. Cachez les erreurs de base de données aux utilisateurs. Message générique pour le client, détail complet dans les journaux serveur.
6. Testez-le, ne le présumez pas. Attaquez vos propres entrées dans un lab et relisez le code source à la recherche de concaténation.

Considérations légales et éthiques

• Testez uniquement sur des systèmes que vous possédez, sur des cibles d'entraînement volontairement vulnérables, ou dans le périmètre défini d'un engagement autorisé.
• Le travail de prévention sur du code de production est sûr et encouragé, mais confirmer un exploit contre des données réelles ne l'est pas. Reproduisez plutôt la faille sur une copie de préproduction ou de lab.
• Si vous trouvez une injection SQL dans l'application de quelqu'un d'autre, signalez-la via son processus de divulgation. N'extrayez pas de données pour prouver l'impact.
• Les labs et cours liés ici existent pour que vous puissiez pratiquer légalement l'attaque et la défense, sur des cibles conçues exactement pour cela.