flawopen.com/SQL Injection/Un ORM suffit-il ?

Utiliser un ORM suffit-il à prévenir l'injection SQL ?

var sql = $"SELECT * FROM dbo.Blogs WHERE Url = '{url}'";
var rows = await context.Blogs
    .FromSqlRaw(sql)
    .ToListAsync();
// User text is inserted into SQL before execution.

var rows = await context.Blogs
    .FromSql($"SELECT * FROM dbo.Blogs WHERE Url = {url}")
    .ToListAsync();
// EF Core 7+: interpolation becomes a SQL parameter.

Le schéma, dans tous les ORM

Les constructeurs ORM et les API SQL brutes ne forment pas une frontière de sécurité uniforme. La documentation décrit la liaison sûre des valeurs avec Django raw(sql, params), SQLAlchemy text() et ses paramètres séparés, les marqueurs Rails, EF Core FromSql (7+) / FromSqlInterpolated, GORM Raw(sql, args...) et $queryRaw balisé de Prisma. Les API diffèrent : FromSqlRaw est sûr avec des paramètres séparés, mais pas si du texte utilisateur est inséré dans la chaîne SQL ; $queryRawUnsafe peut aussi lier des valeurs séparément, mais concaténer du texte non fiable reste dangereux. Le nom d’une méthode ne prouve pas comment elle traite les valeurs. Liez chaque donnée selon le mécanisme documenté. Les identifiants et la structure SQL ne sont pas paramétrables ; choisissez-les dans une liste fixe contrôlée par l’application. Les guides ci-dessous détaillent ces contrats.

Ce que « suffire » exige réellement

• ✓Utilisez le constructeur ORM pour les valeurs et filtres ordinaires.
• ✓En SQL brut, liez chaque valeur avec le mécanisme documenté par l’API.
• ✓Choisissez les identifiants dynamiques dans des listes fixes de l’application ; les paramètres ne lient pas la structure SQL.
• ✓Examinez les appels SQL bruts pour repérer concaténations, interpolations et variantes dangereuses.

FAQ

Références

• Django requêtes SQL
• SQLAlchemy DBAPI
• Rails Active Record
• EF Core requêtes SQL
• GORM sécurité
• Prisma requêtes brutes
• Guide Django
• Guide SQLAlchemy
• Guide Rails
• Guide EF Core
• Guide GORM
• Guide Prisma