/ TL;DR

SQL Injection tem 25 anos de vida e continua nas 3 primeiras posições dos incidentes de 2026 no Brasil. Guia com onde ainda nasce em apps modernos com ORM, os 4 padrões que continuam falhando e como corrigir sem refatorar tudo.

Em 2026, com ORM padrão em quase todo framework, o desenvolvedor médio acha que SQL Injection é problema resolvido. Não é. É a terceira causa mais comum de incidente com PII em apps brasileiros no ano. Este guia mapeia por que ainda acontece e o que blindar sem reescrever o backend.

Onde SQL Injection nasce em app com ORM

Padrão 1: Query bruta "só pra relatório"

O time usa Prisma no dia a dia. Quando precisa de relatório complexo, alguém escreve:

await prisma.$queryRawUnsafe(`SELECT * FROM orders WHERE status = '${req.query.status}'`);

$queryRawUnsafe é a porta de entrada. Correção: $queryRaw com template tag ou parâmetros posicionais.

Padrão 2: Filtros dinâmicos concatenados

query = "SELECT * FROM users WHERE 1=1"
if request.args.get('name'):
    query += f" AND name LIKE '%{request.args['name']}%'"

O ORM nem entra na conversa. Correção: construir com builder de query do ORM, nunca concat.

Padrão 3: ORDER BY / LIMIT com input do usuário

Muitos ORMs sanitizam WHERE mas não ORDER BY. Uma URL ?sort=name; DROP TABLE users -- pode passar.

Correção: allowlist explícita das colunas ordenáveis. Nunca passe o valor bruto.

Padrão 4: Migrations e admin panels caseiros

Ferramentas internas costumam ter query livre "só pro admin". Ninguém audita. Vira RCE via SQL na primeira credencial de admin comprometida.

Correção: painel admin usa mesmo hardening que produção. Zero exceção.

Como testar em 5 minutos

  1. Em qualquer input que vá para WHERE, tente ' OR 1=1 --. Se retornar mais rows, tem injection.
  2. Em qualquer input que vá para ORDER BY, tente 1; SELECT sleep(5) --. Se demorar 5s, tem injection.
  3. Em qualquer campo numérico, tente 1 AND 1=2 UNION SELECT ....

Impacto real em 2026

Nos incidentes reportados à ANPD em 2026 com causa técnica identificada:

  • SQL Injection: 17% dos casos
  • Auth broken (incluindo IDOR): 34%
  • Misconfig (S3 público, .env vazado): 29%
  • SSRF: 8%

Nenhum incidente de SQL Injection em 2026 aconteceu em endpoint que passava pelo ORM padrão sem query bruta. Todos foram no que fugiu do padrão.

Correção em 3 passos

  1. Grep no repo: procure queryRaw, execute(f", execute(" + concat, .raw(, @queryRawUnsafe, cursor.execute com f-string.
  2. Substituir por parametrized. Todo caso encontrado.
  3. Adicionar teste automatizado: um teste que passa ' OR 1=1 -- em cada endpoint que aceita filtro. Se retornar dados adicionais, o teste falha.

O que a Varredura testa

Envia payloads clássicos de SQL Injection em cada campo de cada formulário, cada parâmetro de URL, cada header customizado, cada body de JSON. Compara resposta com baseline. Se comportamento diverge, marca.

TL;DR

  • ORM não protege query bruta escrita à mão.
  • 4 padrões que ainda causam SQL Injection em 2026.
  • 5 minutos de teste manual revela.
  • Grep + substituir + teste no CI resolve.

Rode uma varredura no seu app para ver quais endpoints ainda estão expostos.

EV

Equipe Varredura

Time de pesquisa de segurança · Varredura

Sua app em produção passa por essa análise?

Rode uma varredura autônoma em ~60 segundos. Sem cadastro.

Analisar minha aplicação →