Auditoria de segurança web em 48 horas (Laravel, Node.js, WordPress)

Uma auditoria útil não é um PDF de 80 páginas nem um semáforo de ferramentas em verde. É encontrar o que pode derrubar a aplicação ou vazar dados, provar com evidência e decidir o que corrigir primeiro.

Esta metodologia de 48 horas aplica-se a aplicações PHP/Laravel, Node.js e WordPress (multisite, Elementor, lojas com pagamentos). Quando há ecommerce ou gateways locais, inclui checkout e webhooks — a mesma superfície que costuma gerar incidentes reais.

Por que importa (além do “compliance”)

Pense na segurança como a tranca de uma loja: não substitui o negócio, mas sem ela qualquer pessoa entra. Um achado cedo custa um sprint; um incidente custa clientes, reputação e dias de apagar fogo.

• Dinheiro: pagamentos manipuláveis ou webhooks sem assinatura.
• Dados: pedidos ou usuários visíveis por IDOR.
• Operação: admin sem MFA, plugins abandonados, .env público.
• Prioridade: sem P0/P1/P2, tudo parece urgente e nada fecha.

Conceitos-chave em linguagem clara

• Superfície de ataque: tudo o que um desconhecido pode tocar (formulários, APIs, uploads, admin).
• Autenticação vs autorização: “quem você é” vs “o que pode fazer”. Falhas diferentes.
• IDOR: mudar /orders/100 para /orders/101 e ver o pedido de outra pessoa.
• Injeção: enviar dados que o sistema interpreta como instruções (SQL, XSS, path traversal).
• Dependências: código de terceiros com bugs conhecidos; atualizar também é segurança.

Distribuição das 48 horas

Horas 0–4: mapa de superfície

• Inventário de rotas públicas (web + API).
• Formulários, uploads, webhooks de pagamento, cron endpoints.
• Headers atuais, cookies, redirecionamentos.
• No WordPress: versão, tema filho, plugins ativos, usuários administrator.
• Em multisite: sites, super-admins e plugins de rede.

Horas 4–16: autenticação e sessão

• Reset de senha, enumeração de usuários, rate limiting.
• Cookies Secure / HttpOnly / SameSite.
• CSRF em formulários que alteram estado.
• JWT: exp, rotação, armazenamento inseguro em localStorage.
• Admin WordPress ou Filament/Horizon exposto sem MFA.

Horas 16–32: injeção e lógica de negócio

• SQL / ORM mal usado, XSS armazenado, path traversal.
• Mass assignment no Laravel ($fillable / $guarded).
• IDOR: dá para ver o pedido #id+1?
• Em pagamentos: confirmar que o valor não é confiado ao cliente.
• Upload: tipo real do arquivo, não só a extensão.

Horas 32–48: dependências e entregável

• composer / npm audit com critério (ruído vs risco real).
• Plugins WordPress abandonados ou com advisories conhecidos.
• Secrets no repo, .env exposto, backups públicos.
• Relatório P0/P1/P2 + plano de remediação por sprint.

Laravel: pontos de revisão

• Validação com Form Requests em todas as entradas de API.
• Autorização: Policies/Gates em show/update/destroy.
• Mass assignment: modelos com $guarded = [] ou fillables perigosos.
• Files: Storage com disco privado; URLs assinadas.
• Filas com backoff e dead-letter; payloads sem PII desnecessária.
• APP_DEBUG=false em prod; Telescope/Horizon não públicos.

WordPress: pontos de revisão

• Remover usuário admin genérico; revisar papéis; 2FA em contas privilegiadas.
• XML-RPC: desabilitar se não houver app legítima que precise.
• REST: endpoints de usuários que vazam informação.
• Uploads: bloqueio de execução em uploads.
• WooCommerce: plugins de gateway atualizados; webhooks com permissões mínimas.

Erros comuns ao “auditar”

• Confiar só em um scanner automático sem validar achados à mão.
• Ignorar lógica de negócio (valores, IDs de pedido, permissões por papel).
• Entregar lista de CVEs sem priorizar impacto neste produto.
• Não revisar o deploy: o mesmo secret ou plugin antigo volta no próximo release.
• Marcar tudo como crítico: a equipe satura e não corrige o explorável hoje.

Checklist prático

1. Há .env, .git ou backups acessíveis por URL?
2. Login, reset e APIs sensíveis têm rate limit?
3. Cookies de sessão têm flags corretos em HTTPS?
4. CSRF está ativo em formulários que alteram estado?
5. Policies/capabilities existem e são chamadas em cada rota?
6. Uploads validam MIME real?
7. Webhooks de pagamento validam assinatura/origem e são idempotentes?
8. Headers de segurança (CSP, HSTS) existem sem quebrar o front?
9. Dependências críticas têm dono de atualização?
10. O deploy pode reintroduzir o mesmo secret ou plugin antigo?

Formato do entregável

Cada achado inclui: onde, como reproduzir, risco, correção sugerida e esforço relativo. Conecta com DevOps e Coolify e cibersegurança .