flawopen.com/SQL Injection/¿Basta con un ORM?

¿Basta con usar un ORM para prevenir la inyección 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.

El patrón, en todos los ORM

Los constructores de consultas ORM y las API SQL sin procesar no forman una única frontera de seguridad. La documentación oficial muestra la vinculación segura en Django raw(sql, params), SQLAlchemy text() con parámetros separados, condiciones con marcadores en Rails, EF Core FromSql (7+) / FromSqlInterpolated, GORM Raw(sql, args...) y $queryRaw con etiqueta de plantilla en Prisma. Las API difieren: FromSqlRaw es seguro con parámetros separados, pero no si se inserta texto del usuario en la cadena SQL; $queryRawUnsafe también puede enlazar valores aparte, pero concatenar texto no confiable sigue siendo inseguro. El nombre del método no demuestra cómo trata los valores. Enlaza cada dato con el mecanismo documentado. Los identificadores SQL y la estructura no admiten parámetros; elígelos de una lista fija controlada por la aplicación. Las guías siguientes detallan cada contrato.

Qué exige realmente "basta"

• ✓Usa el constructor de consultas del ORM para valores y filtros habituales.
• ✓En SQL sin procesar, enlaza cada valor mediante los parámetros documentados por la API.
• ✓Elige identificadores dinámicos de listas fijas de la aplicación; los parámetros no enlazan la estructura SQL.
• ✓Revisa llamadas SQL sin procesar para detectar concatenación, interpolación y variantes inseguras.

FAQ

Referencias

• Django consultas SQL
• SQLAlchemy DBAPI
• Rails Active Record
• EF Core consultas SQL
• GORM Seguridad
• Prisma consultas sin procesar
• Guía Django
• Guía SQLAlchemy
• Guía Rails
• Guía EF Core
• Guía GORM
• Guía Prisma