Injection SQL et requêtes paramétrées

L'injection SQL reste l'une des vulnérabilités les plus exploitées : elle survient dès qu'une entrée utilisateur est concaténée dans une requête.

// VULNÉRABLE : l'entrée devient du code SQL
var sql = "SELECT * FROM utilisateurs WHERE email = '" + email + "'";
// email = ' OR 1=1 --   →   renvoie tous les utilisateurs

La défense : les paramètres#

// Sûr : la valeur est transmise séparément du texte de la requête
var cmd = new NpgsqlCommand("SELECT * FROM utilisateurs WHERE email = @email", conn);
cmd.Parameters.AddWithValue("email", email);

-- Côté SQL pur : PREPARE / EXECUTE
PREPARE chercher(text) AS SELECT * FROM utilisateurs WHERE email = $1;
EXECUTE chercher('alice@exemple.fr');

Avec des paramètres, la base ne « réinterprète » jamais la valeur comme du code.

Ce que les paramètres ne couvrent pas#

Un paramètre ne peut représenter qu'une valeur, pas un nom de table, de colonne ou un mot-clé (ORDER BY, ASC/DESC). Pour ceux-là :

• Liste blanche : accepter uniquement des valeurs connues côté application (if (tri is "nom" or "date") ...).
• Côté SQL : format('%I', nom_table) pour un identifiant, format('%L', valeur) pour un littéral, quote_ident() / quote_literal().

Piège : les ORM protègent tant que vous passez par leurs API. Les requêtes brutes (FromSqlRaw, sqlx::query(&format!(...)), db.raw()) avec interpolation de chaînes réintroduisent l'injection. Utilisez leurs versions paramétrées (FromSqlInterpolated, query!, bind).