NoSQL injection: o risco que pega quem usa MongoDB

"Não usamos SQL, então não temos SQL injection." É verdade — mas bancos de documentos como o MongoDB têm sua própria versão do problema, e ela é igualmente perigosa.

Como acontece

Imagine um login assim:

const user = await db.users.findOne({ email: req.body.email, senha: req.body.senha })

Se o atacante enviar {"email": "admin@empresa.com", "senha": {"$ne": null}}, a consulta passa a significar "senha diferente de nulo" — e o login é aceito sem senha.

Por que funciona

APIs em JSON aceitam objetos onde o código esperava texto. Operadores como $ne, $gt e $where viajam junto e mudam o sentido da consulta.

Como se proteger

1. 1.Valide o tipo de cada campo: se é texto, tem que ser texto. Com Zod, um z.string() barra o objeto na entrada (Validação rigorosa de dados: prevenindo falhas de segurança e dados inconsistentes com Zod e TypeScript).
2. 2.Remova operadores de entradas que nunca deveriam contê-los.
3. 3.Nunca compare senha no banco: busque pelo e-mail e verifique o hash na aplicação (Senhas: hash com bcrypt ou Argon2, nunca "criptografia").
4. 4.Evite `$where` e qualquer recurso que execute código no banco.

O padrão por trás

Toda injeção nasce do mesmo erro: tratar dado do usuário como instrução. Vale para SQL (SQL injection em 2026: ainda acontece, e é assim que se previne), para NoSQL e, mais recentemente, para prompts de IA (Prompt injection: o novo SQL injection).

Proteção contra injeção faz parte de Segurança Anti-Hacker na We Codex. Fale com a gente.