flawopen.com/SQL Injection/Um ORM basta?

Usar um ORM basta para prevenir injeção 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.

O padrão, em todo ORM

Construtores de consulta ORM e APIs de SQL bruto não formam uma única fronteira de segurança. A documentação oficial mostra vinculação segura em Django raw(sql, params), SQLAlchemy text() com parâmetros separados, condições com placeholders no Rails, EF Core FromSql (7+) / FromSqlInterpolated, GORM Raw(sql, args...) e $queryRaw com template tag no Prisma. As APIs brutas variam: FromSqlRaw é seguro com parâmetros separados, mas não se texto do usuário for inserido na string SQL; $queryRawUnsafe também pode vincular valores separadamente, mas concatenar texto não confiável continua inseguro. O nome do método não comprova como ele trata os valores. Vincule cada dado pelo mecanismo documentado. Identificadores SQL e estrutura da consulta não podem ser parâmetros; escolha-os de uma lista fixa controlada pela aplicação. Os guias abaixo mostram cada contrato.

O que "basta" realmente exige

• ✓Use o construtor de consultas do ORM para valores e filtros comuns.
• ✓Em SQL bruto, vincule cada valor pelo mecanismo de parâmetros documentado pela API.
• ✓Escolha identificadores dinâmicos em listas fixas da aplicação; parâmetros não vinculam a estrutura SQL.
• ✓Revise chamadas SQL brutas em busca de concatenação, interpolação e variantes inseguras.

FAQ

Referências

• Django consultas SQL
• SQLAlchemy DBAPI
• Rails Active Record
• EF Core consultas SQL
• GORM Segurança
• Prisma consultas brutas
• Guia Django
• Guia SQLAlchemy
• Guia Rails
• Guia EF Core
• Guia GORM
• Guia Prisma