SQL injection em 2026: ainda acontece, e é assim que se previne

É uma das vulnerabilidades mais conhecidas da história da web e, mesmo assim, aparece em auditorias todos os anos. O motivo é simples: basta uma consulta montada concatenando texto do usuário para abrir o banco inteiro.

Como acontece

// NUNCA faça isso
const sql = `SELECT * FROM clientes WHERE email = '${req.query.email}'`

Se alguém enviar ' OR '1'='1, a consulta devolve todos os clientes. Com variações, é possível apagar tabelas ou extrair senhas.

A correção: consultas parametrizadas

const { rows } = await db.query('SELECT * FROM clientes WHERE email = $1', [email])

O valor viaja separado do comando. O banco nunca o interpreta como SQL. ORMs e query builders fazem isso por padrão — o risco volta quando alguém usa a função de "SQL cru" para um filtro complexo.

Onde ainda escapa

• Ordenação dinâmica: ORDER BY ${campo} não aceita parâmetro. Use uma lista de campos permitidos.
• Buscas com LIKE montadas à mão.
• Relatórios com filtros combináveis escritos às pressas.

Camadas extras

1. 1.Validação rigorosa da entrada (Validação rigorosa de dados: prevenindo falhas de segurança e dados inconsistentes com Zod e TypeScript).
2. 2.Usuário do banco com permissões mínimas: a aplicação não precisa de DROP TABLE.
3. 3.Erros do banco nunca devolvidos ao cliente (Tratamento global de erros no Node.js: respostas consistentes e logs úteis).

Bancos de documentos têm seu próprio tipo de injeção — veja NoSQL injection: o risco que pega quem usa MongoDB.

A We Codex revisa e protege sistemas na frente de Segurança Anti-Hacker. Fale com a gente.