Revisão técnica: 08/09/2026.
Para prevenir injeção de SQL em plugins WordPress, mantenha dados e comandos separados com consultas parametrizadas, valide entradas conforme regras de negócio e restrinja permissões. Sanitização genérica ou troca do prefixo das tabelas não corrige uma consulta construída por concatenação. A proteção deve existir em cada caminho que recebe dados não confiáveis.
Use consultas parametrizadas
No WordPress, use os métodos da API e $wpdb->prepare() com marcadores adequados para valores. Não monte SQL juntando texto recebido por formulário, URL, cookie, cabeçalho ou API. A OWASP recomenda consultas preparadas como defesa principal contra injeção de SQL.
Permita somente estruturas conhecidas
Parâmetros normalmente representam valores, não nomes de tabela, coluna ou direção de ordenação. Quando a estrutura precisar variar, converta a opção recebida para uma lista fechada definida no código. Rejeite qualquer valor fora dessa lista. Não aceite um fragmento SQL completo para ganhar flexibilidade.
Valide antes de usar
Confira tipo, formato, tamanho, intervalo e relação com o usuário atual. Sanitizar texto pode remover caracteres, mas não diz se um ID pertence ao cliente ou se o estado solicitado é permitido. A validação deve falhar de forma segura e produzir uma mensagem útil sem revelar a consulta ou detalhes do banco.
Separe autenticação, autorização e nonce
Confirme a identidade e a capacidade necessária para cada ação administrativa. Um nonce ajuda a verificar a intenção de uma requisição dentro de uma sessão, mas não concede permissão. Endpoints AJAX e REST precisam aplicar as mesmas regras do formulário tradicional, incluindo autorização para cada objeto acessado.
Reduza o impacto de uma falha
A conta do banco usada pela aplicação deve ter apenas os privilégios necessários. Não exponha erros de SQL em produção e proteja configurações e backups. Registre falhas e padrões anormais sem gravar senhas, tokens ou dados completos. Backups testados ajudam na recuperação, mas não impedem extração ou alteração indevida.
Teste todos os caminhos de entrada
Revise código, consultas dinâmicas e permissões antes de cada versão. Teste entradas inválidas, repetidas e fora de faixa em ambiente isolado. Atualize dependências e acompanhe avisos de segurança. Para resposta administrativa, veja como agir quando um plugin está vulnerável. Para outra classe de injeção, consulte como prevenir XSS no WordPress.
