Evitando SQL injection: as 5 práticas essenciais para devs WordPress

Em 2026, os ataques de SQL injection continuam sendo uma das principais causas de invasão em sites WordPress. E o motivo quase sempre é o mesmo: código mal escrito que permite a um atacante manipular consultas ao banco de dados. Se você desenvolve plugins, temas ou qualquer funcionalidade personalizada, conhecer e aplicar as práticas corretas para evitar SQL injection não é opcional – é obrigação. Este guia mostra as 5 práticas essenciais que todo dev WordPress deve dominar.

O que é SQL injection (na prática)

Imagine que você tem uma consulta que busca um usuário pelo ID passado na URL:

$user_id = $_GET['id'];
$query = "SELECT * FROM wp_users WHERE ID = $user_id";
$results = $wpdb->get_results($query);

Um atacante pode enviar algo como: ?id=1 OR 1=1; DROP TABLE wp_users; --. O resultado: a query se torna SELECT * FROM wp_users WHERE ID = 1 OR 1=1; DROP TABLE wp_users; -- – todos os usuários são retornados e a tabela é deletada. Simples, devastador, e infelizmente comum.

As 5 práticas essenciais

// ❌ ERRADO
$user_id = $_GET['id'];
$query = "SELECT * FROM wp_users WHERE ID = $user_id";
$user = $wpdb->get_row($query);

// ✅ CORRETO
$user_id = absint($_GET['id']);
$query = $wpdb->prepare("SELECT * FROM wp_users WHERE ID = %d", $user_id);
$user = $wpdb->get_row($query);

// ✅ Recomendado (abstração segura)
$user = get_user_by('id', $user_id);

// ✅ Alternativa com $wpdb (ainda segura)
$user = $wpdb->get_row($wpdb->prepare("SELECT * FROM $wpdb->users WHERE ID = %d", $user_id));

$user_id = isset($_GET['id']) ? absint($_GET['id']) : 0;
if ($user_id === 0) {
    wp_die('ID inválido');
}

// Verifica se o usuário atual pode editar posts
if (!current_user_can('edit_posts')) {
    wp_die('Acesso negado');
}

// Verifica nonce para ações via POST
if (!wp_verify_nonce($_POST['nonce'], 'meu_plugin_action')) {
    wp_die('Nonce inválido');
}

$search = '%' . $wpdb->esc_like($user_input) . '%';
$query = $wpdb->prepare("SELECT * FROM $wpdb->posts WHERE post_title LIKE %s", $search);
$results = $wpdb->get_results($query);

Exemplo prático: formulário de busca vulnerável vs. seguro

Código vulnerável (NUNCA use):

$search = $_POST['search'];
$query = "SELECT * FROM wp_posts WHERE post_title LIKE '%$search%'";
$results = $wpdb->get_results($query);

Código seguro (use assim):

$search = sanitize_text_field($_POST['search']);
$search_like = '%' . $wpdb->esc_like($search) . '%';
$query = $wpdb->prepare("SELECT * FROM $wpdb->posts WHERE post_title LIKE %s", $search_like);
$results = $wpdb->get_results($query);

Ferramentas para detectar SQL injection no seu código

• Query Monitor – mostra todas as queries executadas. Verifique se alguma está concatenando variáveis diretamente.
• PHPStan com extensão WordPress – análise estática que detecta uso incorreto de $wpdb.
• Semgrep – regras personalizadas para buscar padrões de concatenação em SQL.
• WordPress Coding Standards (PHPCS) – as regras WordPress.DB.PreparedSQL e WordPress.DB.DirectDatabaseQuery apontam más práticas.

E se você está usando WP_Query ou funções de alto nível?

Ótimo! Funções como WP_Query, get_posts, get_metadata, get_terms já sanitizam os parâmetros internamente. Por exemplo:

$args = [
    's' => $_GET['s'],        // busca por texto livre
    'post_type' => 'post',
];
$query = new WP_Query($args);

Mesmo assim, sanitize os parâmetros antes de passar para o array, especialmente 's' (busca) e 'meta_query' valores.

O que fazer se seu site foi atacado?

1. Isole o site (modo manutenção ou bloqueio por IP).
2. Restaure backup limpo (anterior ao ataque).
3. Verifique logs de acesso e de erros (seu servidor e o debug.log do WordPress).
4. Instale um firewall de aplicação (WAF) temporariamente.
5. Audite todos os plugins e temas customizados em busca de SQL injection (use as ferramentas citadas).
6. Altere todas as senhas (admin, FTP, banco de dados).
7. Após corrigir, remova o WAF e reative o site.

Em caso de invasão confirmada, considere contratar um especialista em segurança para limpeza profunda.

Conclusão: segurança é processo, não produto

Aplicar as 5 práticas acima reduz drasticamente o risco de SQL injection no WordPress. Mas lembre-se: a segurança nunca é definitiva. Mantenha-se atualizado sobre novas vulnerabilidades, use plugins de segurança (ex: Wordfence, Sucuri) e sempre revise seu código ou o de terceiros.

Resumo rápido:

• ✅ Sempre use $wpdb->prepare() com placeholders.
• ✅ Sanitize e valide todos os inputs externos.
• ✅ Para consultas LIKE, use esc_like() antes de prepare().
• ✅ Prefira funções de alto nível (WP_Query, get_user_by).
• ✅ Adicione nonces e verificações de capacidade.

Você já sofreu ou encontrou SQL injection em algum projeto? Compartilhe sua experiência com outros profissionais e vamos fortalecer a segurança da comunidade WordPress.