O que é uma injeção SQL e como evitá-la ao criar um site?

Publicado em 2026-10-20 por frfrand

SQL injection explicada para principiantes: qué ocurre al mezclar consultas y datos, por qué funcionan las consultas parametrizadas y cómo reducir riesgos.

Uma injeção SQL é uma vulnerabilidade que aparece quando uma aplicação incorpora dados não confiáveis dentro de instruções SQL de forma insegura. Em determinadas condições, um atacante pode fazer com que o mecanismo de banco de dados interprete parte desses dados como código e execute uma consulta diferente da prevista.

A ideia essencial é muito simples: uma coisa são os dados que uma pessoa escreve e outra são as instruções que o programa decide executar. Confundi-los é o problema.

O exemplo de uma planilha de pedidos

Imagine que você atende uma loja. Seu sistema permite buscar um produto pelo nome. O correto seria usar o nome como dado dentro de uma consulta já definida.

Mas um programa mal projetado poderia fabricar a consulta unindo fragmentos de texto com o que o usuário escreveu. Assim, alguém pode tentar introduzir caracteres ou instruções que alterem o significado da busca.

Não precisamos construir um ataque para entender o erro: ocorre porque o programa deixa que o conteúdo externo intervenha na estrutura de uma instrução.

O que poderia acontecer?

Dependendo das permissões da conta utilizada pela aplicação e de como as consultas são construídas, a falha pode permitir obter informações que não correspondem, modificar registros ou afetar a disponibilidade do serviço.

Isso não significa que toda injeção SQL conceda controle completo do servidor. O impacto depende de múltiplos fatores: consultas possíveis, mecanismo utilizado, permissões e arquitetura.

Por isso, limitar os privilégios do usuário do banco de dados é uma proteção adicional valiosa, embora não corrija a vulnerabilidade de origem.

Como evitar? Consultas parametrizadas

A defesa mais importante consiste em separar a estrutura SQL dos valores externos. As consultas parametrizadas utilizam marcadores de posição e passam os dados à parte, para que o mecanismo os trate como valores e não como fragmentos de código SQL.

Em Python com um driver compatível, um exemplo conceitual seria:

cursor.execute(
    "SELECT id, nombre FROM productos WHERE nombre = %s",
    (nombre_buscado,)
)

O marcador utilizado depende da biblioteca. O importante não é copiar literalmente esse símbolo em qualquer linguagem, mas sim utilizar o mecanismo oficial de parâmetros do driver.

Não é recomendado construir a consulta concatenando manualmente aspas ao redor do dado. Escapar caracteres à mão costuma ser frágil e muito fácil de fazer errado.

E os ORMs?

Frameworks como o Django incluem um ORM que permite realizar muitas consultas sem escrever SQL manualmente. Isso costuma reduzir o risco quando suas operações e filtros são utilizados corretamente.

Mas usar um ORM não te torna imune. Se você executar consultas SQL brutas, construir expressões dinâmicas inseguras ou aceitar nomes de colunas e tabelas sem controle, ainda poderá introduzir problemas.

Para partes dinâmicas que não admitem parametrização direta —como alguns identificadores SQL— são necessárias listas explícitas de valores permitidos e métodos adequados do provedor.

Serve validar o formulário?

Validar ajuda a que os dados cumpram as regras de negócio, mas não substitui a parametrização.

Que uma pessoa só possa inserir vinte caracteres não demonstra que o valor seja seguro para qualquer contexto. As proteções devem ser aplicadas onde a consulta é construída.

Também convém verificar as permissões do usuário do banco de dados: um aplicativo que apenas lê um conjunto de tabelas não deveria receber privilégios administrativos ilimitados.

E um firewall de aplicações?

Um WAF pode bloquear determinados padrões maliciosos, mas não corrige o código vulnerável. Algumas requisições prejudiciais podem passar e outras legítimas poderão ser bloqueadas por engano.

A solução robusta começa dentro do aplicativo, com parâmetros, autorização e testes.

Como testar defensivamente?

Revise os pontos que aceitam informações externas, utilize testes automatizados e ferramentas de análise apropriadas dentro de um ambiente autorizado. Verifique as consultas que o código constrói e certifique-se de que os valores nunca sejam interpretados como instruções.

Em produção, evite exibir erros SQL detalhados ao público, pois eles podem revelar informações internas. Mantenha registros úteis para diagnóstico em um sistema protegido.

Onde entra o ArduMaker?

Se você hospeda um aplicativo Django, Node ou qualquer backend com PostgreSQL no ArduMaker, as consultas são de responsabilidade do seu aplicativo. O servidor pode manter o banco de dados em uma rede privada, mas isso não substitui a parametrização nem o controle de permissões.

Em resumo: a injeção SQL aparece quando os dados cruzam a fronteira e se tornam ordens. Manter essa separação é a defesa principal.

Fontes: Prevención de SQL Injection en OWASP · Guía de PostgreSQL · Cómo se compromete una base de datos.