Auditoria de segurança web em 48 horas: Laravel, Node.js e WordPress

Uma auditoria útil não é teatro de ferramentas verdes. É encontrar o que pode derrubar a aplicação ou vazar dados, documentar com evidência e priorizar o que corrigir primeiro.

Esta metodologia 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 coberta por pagamentos online.

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.
• 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.

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?

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.

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 .