# SQL injection prevencao: 7 praticas essenciais para sua aplicacao

> SQL injection (SQLi) permanece entre as ameaças mais prevalentes em aplicações web. A prevenção eficaz exige sete práticas essenciais: uso de consultas parametrizadas, validação rigorosa de entrada, aplicação do princípio do menor privilégio, escape adequado de caracteres especiais, implementação de stored procedures, atualização constante de bibliotecas e monitoramento contínuo de logs. SQLi reduz a superfície de ataque quando essas camadas defensivas operam em conjunto, sem depender de um único ponto de proteção.

*Bombou na Web · Tecnologia · 07 de setembro de 2026 · Otávio Bensaúde*

SQL injection (SQLi) segue entre as ameacas mais comuns em aplicacoes web. Estas 7 praticas, da parametrizacao ao monitoramento, reduzem a superficie de ataque sem depender de um unico ponto de defesa.

SQL injection (SQLi) ocorre quando uma entrada do usuario e interpretada como codigo SQL, permitindo leitura ou alteracao indevida do banco. A prevencao exige mais que uma unica correcao: envolve praticas de codigo, configuracao e monitoramento que atuam em camadas. Abaixo, as 7 praticas essenciais para reduzir a superficie de ataque.

## 1. Use consultas parametrizadas (prepared statements)

A parametrizacao separa o codigo SQL dos dados fornecidos pelo usuario. Em vez de concatenar strings, voce envia a consulta com placeholders e passa os valores separadamente. Isso impede que a entrada seja interpretada como instrucao, independentemente do conteudo. Bancos como PostgreSQL, MySQL e SQL Server suportam prepared statements nativamente. Em Java, use PreparedStatement; em Python, os parametros de cursor.execute(); em PHP, PDO com bindValue. Nenhuma outra pratica substitui essa barreira, que elimina a maioria dos vetores de SQLi.

## 2. Valide e higienize toda entrada do usuario

Mesmo com parametrizacao, a validacao reduz riscos residuais. Defina regras por campo: tipo esperado (numero, data, email), tamanho maximo e intervalo de valores. Rejeite entradas que nao atendam ao formato, em vez de tentar limpar o conteudo. Por exemplo, um campo de CPF deve aceitar apenas 11 digitos; qualquer outro valor e descartado. A higienizacao complementar, como remover caracteres de controle, protege contra falhas em bibliotecas ou em consultas nao parametrizadas legadas.

## 3. Aplique o principio do minimo privilegio no banco

A conta usada pela aplicacao nao deve ter permissoes de administrador. Crie usuarios dedicados com acesso apenas as tabelas e operacoes necessarias. Se a aplicacao so le dados, conceda somente SELECT. Isso limita o dano caso um ataque consiga executar instrucoes: um invasor nao podera apagar tabelas ou criar usuarios. Revise permissoes periodicamente, principalmente em ambientes que acumulam contas ao longo do tempo.

## 4. Evite concatenacao de strings em consultas dinamicas

Consultas montadas por concatenacao, mesmo com aspas escapadas, sao a causa classica de SQLi. A pratica de adicionar "escape de aspas simples" manualmente e fragil: codificacoes alternativas ou erros de codificacao podem burlar a protecao. Prefira construir consultas com ferramentas que parametrizam automaticamente. Se a dinamica for inevitavel, por exemplo em filtros com ordenacao, use uma lista branca de colunas e direcoes permitidas, nunca o valor bruto do usuario.

## 5. Utilize um ORM ou query builder com seguranca padrao

Frameworks como Hibernate (Java), Entity Framework (.NET), SQLAlchemy (Python) e Prisma (Node.js) geram consultas parametrizadas por padrao. Isso reduz erros humanos, pois o desenvolvedor nao escreve SQL cru. Porem, ORMs nao sao infaliveis: recursos como query bruta ou execucao de SQL nativo reintroduzem o risco. Ao usar essas funcionalidades, aplique as mesmas regras de parametrizacao manuais. A escolha do ORM depende da linguagem e da equipe, mas qualquer um deles e mais seguro que SQL puro concatenado.

## 6. Configure o WAF e monitore logs de banco

Um Web Application Firewall (WAF) pode bloquear requisicoes com padroes conhecidos de SQLi antes que cheguem ao servidor. Solucoes como Cloudflare ou ModSecurity oferecem regras predefinidas e atualizacoes constantes. Paralelamente, monitore logs do banco e da aplicacao para detectar tentativas: erros de sintaxe SQL em sequencia, queries anormais ou acessos fora do padrao. Alertas em tempo real permitem resposta rapida. Lembre-se: WAF e monitoramento reduzem o impacto, mas nao corrigem codigo vulneravel.

## 7. Realize testes de seguranca e revisao de codigo

Testes automatizados com ferramentas como OWASP ZAP ou sqlmap ajudam a identificar pontos de injecao antes da publicacao. Inclua casos de teste com entradas maliciosas (aspas, operadores logicos, comentarios SQL) em sua suite. A revisao de codigo por pares, com checklist de seguranca, captura falhas que ferramentas nao veem. Realize esses testes a cada alteracao relevante, nao apenas em auditorias anuais. A combinacao de automacao e revisao humana cobre tanto erros conhecidos quanto logicas complexas.

## Qual pratica adotar primeiro?

Se voce esta comecando, implemente a parametrizacao em todas as consultas novas. E o passo de maior impacto e menor custo. Em seguida, ajuste as permissoes do banco e revise codigo legado. Para aplicacoes em producao, habilite um WAF e monitore logs enquanto o codigo e corrigido. Nenhuma pratica isolada e suficiente: a defesa em profundidade, com pelo menos tres das camadas acima, e o cenario recomendado.

## FAQ

### O que e SQL injection?

SQL injection e uma tecnica de ataque em que o invasor envia entradas maliciosas que sao interpretadas como parte de uma instrucao SQL. Isso permite ler, modificar ou apagar dados do banco, dependendo das permissoes da conta usada pela aplicacao.

### Validar entrada elimina a necessidade de parametrizacao?

Nao. Validacao reduz a superficie de ataque, mas nao elimina o risco, pois regras podem ser imperfeitas ou esquecer casos limites. A parametrizacao e a unica barreira que impede a interpretacao de entrada como codigo, independentemente do conteudo.

### ORMs previnem SQL injection automaticamente?

A maioria dos ORMs gera consultas parametrizadas por padrao, o que previne SQLi em uso normal. Mas recursos de SQL bruto ou consultas nativas exigem cuidado manual. Sempre que usar esses recursos, aplique parametros, nunca concatenacao.

### Como detectar SQL injection em uma aplicacao existente?

Use ferramentas de teste como OWASP ZAP ou sqlmap para escanear endpoints em ambiente controlado. Monitore logs de erro e de banco por queries anormais. Uma revisao de codigo focada em concatenacao de strings e o metodo mais confiavel.

### O que fazer se uma aplicacao ja sofreu um ataque SQLi?

Isole o servidor afetado, revise logs para identificar a extensao do acesso e altere credenciais do banco. Restaure dados de backup limpo, se necessario, e corrija a vulnerabilidade com parametrizacao antes de colocar no ar novamente.

### WAF substitui boas praticas de codigo?

Nao. WAF bloqueia padroes conhecidos, mas nao entende o contexto da sua aplicacao. Ataques sofisticados ou codificacoes alternativas podem passar. Codigo seguro, com parametrizacao e validacao, e a defesa primaria; WAF e uma camada complementar.

---

Fonte (canonical): https://www.bombounaweb.com.br/tecnologia/sql-injection-prevencao-7-praticas-essenciais-para-sua-aplicacao/