Auditoria de Segurança do WordPress: O que verificar antes de publicar

Antes que qualquer plugin gerado pelo PAGEnza chegue à instalação WordPress de um usuário, ele passa por três verificações de segurança automatizadas. Este post explica o que essas verificações procuram — e por que cada uma delas é importante.

Por que o código gerado por IA precisa de auditoria

Grandes modelos de linguagem são surpreendentemente bons em escrever plugins WordPress. Eles conhecem nomes de hooks, entendem os padrões de codificação do WP, produzem PHP legível. Mas eles também cometem erros previsíveis — e esses erros são vulnerabilidades de segurança.

Os mais comuns que vemos:

• Uso de $_GET ou $_POST sem sanitização
• Falta de verificação de nonce em envios de formulário
• Consultas diretas ao banco de dados sem $wpdb->prepare()
• Uso de eval() ou exec() para comportamento dinâmico
• Saída de dados do usuário sem esc_html() ou esc_attr()

Estes não são casos extremos exóticos. Eles aparecem regularmente na saída de LLMs — mesmo dos melhores modelos.

Etapa 1: Validação do prompt

Antes que a IA escreva uma única linha, analisamos a descrição do usuário. Esta etapa detecta duas categorias de problemas:

Tentativas de manipulação — prompts tentando fazer com que a IA produza código deliberadamente malicioso. Coisas como "ignore as instruções anteriores" ou "crie um backdoor para testes".

Descrições vagas ou inviáveis — prompts muito curtos ou ambíguos para produzir código útil. "Faça um plugin" gera lixo; "Crie um formulário de contato que envie envios para um endereço de e-mail com filtragem de spam" gera algo real.

Se um prompt falhar nesta verificação, o usuário verá um erro específico explicando o porquê — não uma rejeição genérica.

Etapa 2: Linting de PHP em um contêiner isolado

Assim que a IA produz código PHP, ele é executado através de php -l dentro de um contêiner Docker que está completamente isolado de todo o resto. Isso detecta erros de sintaxe antes que o plugin chegue a uma instalação WordPress.

Mas vamos além: se o linting falhar, o sistema não rejeita apenas a saída. Ele envia o erro de volta para a IA com um prompt de correção — o que chamamos de cura (healing). A IA vê seu próprio erro e tenta novamente, até três vezes.

Isso significa que os usuários quase nunca veem uma mensagem de "geração falhada". Eles veem um tempo de geração um pouco mais longo — e código funcional.

Etapa 3: Verificação de segurança do código

Esta é a etapa mais importante. Executamos uma análise estática que verifica:

Funções perigosas: eval(), exec(), system(), shell_exec(), passthru() — qualquer uma delas bloqueia a liberação do plugin.

Vetores de injeção de SQL: chamadas $wpdb->query() brutas com variáveis interpoladas, falta de $wpdb->prepare(), uso direto de mysql_query().

Falta de verificações de permissão: manipuladores AJAX que não chamam current_user_can() antes de fazer qualquer coisa privilegiada.

Falta de verificação de nonce: processadores de formulário que não chamam wp_verify_nonce() ou check_ajax_referer().

Saída sem escape: echo $_GET[...], echo $user_input sem funções de escape.

Se algum desses for encontrado, o plugin é bloqueado. O usuário vê um relatório listando exatamente quais funções acionaram o bloqueio e por quê — não apenas "verificação de segurança falhou".

Como é o relatório de auditoria

Cada plugin gerado vem com um relatório de auditoria de segurança em linguagem clara. Ele lista:

• Quais verificações passaram (verde)
• Quais verificações acionaram avisos (âmbar) — problemas que não são bloqueadores, mas merecem atenção
• Quaisquer correções que foram aplicadas automaticamente durante a cura

O relatório é gerado automaticamente e anexado ao download do plugin. É útil tanto para sua confiança quanto para mostrar aos clientes que você levou a segurança a sério.

Etapa 4: Validação ao salvar

Esta não faz parte da geração inicial — aplica-se quando os usuários editam manualmente o código do plugin no editor PAGEnza.

Cada vez que você salva, a mesma verificação de lint + segurança é executada novamente. Se você introduzir uma vulnerabilidade crítica durante a edição, o salvamento será bloqueado até que você a corrija. Isso evita o cenário comum em que um desenvolvedor faz uma alteração rápida "temporária" que permanece em produção por dois anos.

Os limites da auditoria automatizada

A verificação automatizada detecta bem uma classe específica de problemas. Ela não detecta tudo.

Erros de lógica, lógica de negócios quebrada e problemas sutis de escalonamento de privilégios que não envolvem padrões perigosos conhecidos ainda exigem revisão humana. Somos transparentes sobre isso na documentação — a auditoria não é um substituto para uma revisão de segurança, é um piso que garante um padrão mínimo.

Para plugins de produção que lidam com pagamentos ou dados sensíveis, recomendamos uma revisão manual além das verificações automatizadas. O relatório de auditoria fornece um bom ponto de partida para um revisor humano.