Dicas Gerais

Como prevenir SQL Injection em aplicações PHP

Separe valores da consulta com parâmetros e revise validação e permissões do banco. Veja critérios, cuidados e etapas para aplicar a orientação corretamente.

Revisão técnica: 08/09/2026. SQL Injection ocorre quando dados recebidos pela aplicação passam a modificar a estrutura de uma consulta. Um formulário de busca, um identificador na URL ou uma rotina de importação podem alcançar o banco; a revisão precisa acompanhar esses caminhos.

Separe a consulta dos valores

Use consultas parametrizadas. Instanciar PDO não resolve o problema se o código continuar concatenando entradas no SQL antes de chamar prepare(). No exemplo abaixo, a conexão PDO já existe em $pdo, com tratamento de exceções configurado, e a tabela ilustrativa contém artigos públicos.

$id = filter_input(INPUT_GET, 'id', FILTER_VALIDATE_INT);
if ($id === false || $id === null || $id < 1) {
    http_response_code(400);
    exit('Identificador inválido');
}
$consulta = $pdo->prepare(
    'SELECT titulo FROM artigos WHERE id = :id AND publicado = 1'
);
$consulta->bindValue(':id', $id, PDO::PARAM_INT);
$consulta->execute();
$artigo = $consulta->fetch(PDO::FETCH_ASSOC);

Adapte o esquema ao projeto e trate separadamente o caso de registro inexistente. O marcador representa um valor completo, sem aspas ao redor dele. Nomes de tabelas, colunas e direções de ordenação precisam vir de opções permitidas pelo código; não podem ser substituídos por parâmetros de valores.

Revise além do formulário

Valide formato e limites conforme a função de cada campo. Não use addslashes() como defesa de SQL, nem recupere exemplos da antiga extensão mysql_*. Revise também consultas construídas por relatórios, filtros administrativos e importações. Uma biblioteca de acesso ao banco pode oferecer parâmetros, mas trechos SQL montados manualmente continuam exigindo análise.

A conta do banco deve ter apenas as permissões necessárias à aplicação. Registre falhas em local restrito e devolva mensagens controladas ao visitante, sem consultas, credenciais ou detalhes internos.

Verifique o comportamento esperado

Em ambiente de testes, confira identificadores válidos, ausentes e inválidos, além de textos legítimos com apóstrofos nos campos que aceitam texto. Revise se cada entrada chega ao banco como dado. Parametrização não substitui a autorização para acessar registros nem a codificação de saída HTML.

Referências: PDO::prepare no manual do PHP e prevenção de SQL Injection da OWASP.