SQL injection é uma vulneridade onde um atacante insere SQL malicioso através de entrada do usuário — manipulando consultas de banco de dados para roubar dados, contornar autenticação ou danificar dados. É uma das vulneribilidades mais perigosas e clássicas da web, mas é prevenível com técnicas apropriadas.
When user input is concatenated directly into a SQL query, an attacker can INJECT SQL:
query = ;
A entrada do atacante é tratada como código SQL em vez de dados — permitindo que eles reescrevam a consulta (contornar login, despejar todos os dados, deletar tabelas).
// ✅ PARAMETERIZED / PREPARED statements — input is treated as DATA, never as code
const query = 'SELECT * FROM users WHERE email = ?';
db.execute(query, [userInput]); // the value is safely bound, not concatenated
// → the database treats userInput as a literal value → injection impossible
Consultas parametrizadas (prepared statements) separam código SQL de dados — a entrada nunca pode ser interpretada como SQL. Esta é a defesa primária e confiável.
✓ PARAMETERIZED queries / prepared statements → the #1 fix (always use them)
✓ ORMs/query builders → use parameterization under the hood (but don't bypass with raw
string concatenation)
✓ INPUT VALIDATION (defense in depth) — validate/sanitize, but NOT a substitute for
parameterization
✓ LEAST PRIVILEGE DB accounts (limit damage); avoid exposing detailed DB errors
→ NEVER build queries by concatenating user input.
Entender SQL injection e como preveni-la é essencial porque é uma das vulneribilidades mais perigosas, clássicas e comuns da web (parte da categoria de injeção OWASP), ainda assim inteiramente prevenível, portanto é conhecimento de segurança imprescindível para qualquer desenvolvedor que trabalha com bancos de dados.
Entender como funciona — que concatenar entrada do usuário diretamente em consultas SQL permite que um atacante injete código SQL (sua entrada tratada como código em vez de dados), possibilitando contornar autenticação (' OR '1'='1), despejar todos os dados ou até deletar tabelas ('; DROP TABLE) — é necessário para reconhecer e evitar a vulneribilidade.
SQL injection pode ser catastrófico (violação completa de dados, destruição de dados, contorno de autenticação), tornando-a criticamente importante.
Entender a prevenção é essencial: consultas parametrizadas (prepared statements) são o principal corretor confiável — elas separam código SQL de dados para que a entrada do usuário seja tratada como um valor literal que nunca pode ser interpretado como SQL, tornando a injeção impossível.
Esta é a defesa #1 que todo desenvolvedor deve usar.
Entender as defesas adicionais — usar ORMs/query builders (que parametrizam, mas não os contornando com concatenação crua), validação de entrada como defesa em profundidade (mas não um substituto para parametrização), contas de banco de dados com privilégios mínimos e evitar exposição de erros detalhados — e a regra cardinal de nunca concatenar entrada do usuário em consultas reflete prevenção abrangente.
Como SQL injection é uma vulnerabilidade perigosa, comum e clássica com consequências graves (violação de dados, perda de dados, contorno de autenticação) que é inteiramente prevenível com consultas parametrizadas, e como entender como funciona e como preveni-la é essencial para qualquer desenvolvedor que trabalha com bancos de dados, entender SQL injection e sua prevenção é conhecimento de segurança essencial e imprescindível — uma vulnerabilidade fundamental para entender e defender, onde o corretor simples e confiável (consultas parametrizadas) é conhecimento crítico que previne uma das classes de ataques mais prejudiciais.