Web Security Review

Premissa: código gerado por IA é código não confiável até passar por validação, testes e revisão de segurança. Isso vale para o código que você está revisando e para o que você mesmo acabou de escrever.

Sempre nesta ordem: detectar → escanear → revisar → classificar → reportar → corrigir. Nunca corrija antes de reportar — a pessoa decide o que entra.

A referência completa (riscos, exemplos, checklists por tema) está em checklist.md nesta pasta. Este arquivo é o procedimento.

ls composer.json package.json requirements.txt pyproject.toml go.mod Dockerfile .env .env.example 2>/dev/null

Se houver sinais de LLM, a seção 5 é obrigatória. Verifique também quais scanners estão instalados (which gitleaks semgrep trivy) — use os que existirem; não instale nada sem perguntar.

Rode o que se aplica e guarde a saída para o relatório:

Sem gitleaks, faça a busca básica de secrets:

grep -rnE "(sk-[A-Za-z0-9]{20,}|AKIA[0-9A-Z]{16}|ghp_[A-Za-z0-9]{36}|-----BEGIN (RSA |EC )?PRIVATE KEY|password\s*=\s*['\"][^'\"]{6,}|api[_-]?key\s*[:=]\s*['\"][^'\"]{10,})" \
  --include=*.{js,ts,php,py,env,json,yml,yaml} --exclude-dir={node_modules,vendor,.git,dist,build} .

Confira também se .env está no .gitignore e se nunca foi commitado (git log --all --oneline -- .env).

Grep é triagem, não veredito: abra cada match e confirme se a entrada é controlada pelo usuário e se existe validação/escape antes. Só reporte o que confirmou.

• Rota que recebe id na URL e busca direto (find($id), findById(req.params.id)) sem checar o dono (where user_id = auth(), policy, guard) → IDOR.
• Laravel: $request->all() em create/update sem $fillable/$guarded → mass assignment.
• Middleware de auth ausente em rota que muda estado; checagem só no front-end.
• Multi-tenant: consulta sem filtro de tenant_id.

• Path traversal: caminho montado com entrada do usuário (path.join(base, req.query.file), storage_path($name)) sem normalizar e conferir que ficou dentro da base.
• Upload: extensão/MIME não validados, arquivo servido do mesmo domínio, nome original mantido.
• SSRF: fetch(url), axios.get(url), Http::get($url), file_get_contents($url), requests.get(url) com URL vinda do usuário, sem allowlist de domínio e bloqueio de IP privado.
• CORS * com credenciais; cookies sem HttpOnly/Secure/SameSite.
• Redirect com destino vindo da query (redirect($request->url)) sem allowlist.

• include/require/include_once com caminho vindo de entrada (include($_GET['page']), require "pages/$name.php") → LFI; com allow_url_include=On, vira RFI (código remoto).
• Node: require(userInput), import(userInput), res.render(req.query.view); Python: __import__(name), importlib.import_module(user), open(path) com caminho externo.
• Seguro: allowlist de nomes válidos (['home','about']), nunca o caminho; allow_url_include=Off.

• Bypass: rota que muda estado sem middleware de auth; auth checada só no front; if (user) onde user pode vir do cliente (header/cookie forjável, X-User-Id); endpoint de debug/admin esquecido (/debug, /admin sem guard); ordem errada de middleware (handler antes do auth).
• JWT: sem expiração; sem verificar assinatura (alg: none, verify: false, decode() em vez de verify()); segredo fraco/hardcoded; aceitar token de outro emissor/audience; sem revogação.
• Brute force: sem rate limit em login/reset/OTP/2FA; sem bloqueio ou atraso progressivo após tentativas; enumeração de usuário por mensagem diferente ("senha errada" vs "usuário não existe").
• Session fixation: id de sessão não regenerado no login (session()->regenerate(), req.session.regenerate(), request.session.cycle_key()); id aceito pela URL ou por cookie pré-existente.
• Session hijacking: cookie sem HttpOnly/Secure/SameSite; sessão sem expiração ou sem invalidação no logout e na troca de senha; token de sessão em URL, log ou localStorage exposto a XSS.
• Comparação de token/hash com == em vez de comparação em tempo constante.
• Senha com hash fraco (MD5/SHA1) ou sem salt; bcrypt/argon2 é o esperado.

• Padrão ler → decidir → gravar sem lock ou transação em recurso disputado: saldo, estoque, cupom de uso único, "já votou?", limite de uso — permite gastar/usar duas vezes com requisições simultâneas.
• Seguro: SELECT ... FOR UPDATE / lockForUpdate() dentro de transação; UPDATE ... WHERE saldo >= ? atômico; constraint UNIQUE para "uma vez só"; chave de idempotência em operações de pagamento.
• Teste negativo: disparar N requisições em paralelo e conferir que só uma passa.

• Stack trace, query ou payload retornados ao cliente (APP_DEBUG=true em produção, app.use(errorHandler) que vaza err.stack).
• Dado pessoal, token ou senha em log, em URL (?token=) ou em resposta de API além do necessário (serializar o model inteiro: return $user, res.json(user) com hash/e-mail/documento).
• Tráfego sem TLS; .git/, .env, backups ou phpinfo servidos publicamente; listagem de diretório.
• Dado sensível armazenado em claro quando deveria ser hash ou cifrado; sem mascaramento em telas/logs.

Além do audit: versões fixadas e lockfile versionado; pacotes com nome parecido com o de uma lib conhecida (typosquatting); dependência adicionada só para uma função trivial; implementação própria de cripto/auth onde existe solução consolidada; imagem Docker latest ou sem scan (trivy image se houver).

Trate como fronteira de confiança nova — o modelo não é camada de segurança.

Regra de arquitetura a cobrar: INPUT → VALIDATE → AUTHENTICATE → AUTHORIZE → LLM → VALIDATE OUTPUT → BUSINESS RULES → EXECUTE → AUDIT. Nunca INPUT → LLM → EXECUTE.

Falso positivo confirmado não entra no relatório. Achado que você não conseguiu confirmar entra como "a verificar", separado.

Sempre antes de corrigir. Formato:

## Security Review — <projeto ou PR #N>
Stack: Laravel 11 · Node 20 (front) · usa OpenAI SDK
Ferramentas: composer audit ✓ · npm audit ✓ · gitleaks ✗ (não instalado) · semgrep ✗

### Resumo
🔴 2 · 🟠 3 · 🟡 4 · 🔵 2 · a verificar: 1

### Achados
🔴 SQL injection — app/Http/Controllers/ReportController.php:48
   `DB::select("... WHERE status = '$status'")` com $status vindo da query string.
   Correção: binding `DB::select('... WHERE status = ?', [$status])`.

🟠 IDOR — routes/api.php:31 + OrderController@show
   `Order::findOrFail($id)` sem checar o dono. Correção: `auth()->user()->orders()->findOrFail($id)` ou Policy.
…

### Dependências
composer audit: 1 pacote com CVE (…) · npm audit: 3 high, 12 moderate

### Recomendação
Bloquear merge até resolver as 🔴. As 🟠 entram no mesmo PR ou em card próprio, à escolha do time.

Cada achado tem arquivo:linha, o que é, por que é explorável e a correção proposta. Sem os quatro, não é achado — é palpite.

• Um achado por vez, começando pelas 🔴. Peça confirmação antes de mexer em autenticação, autorização ou cripto — são as mudanças com mais efeito colateral.
• Corrija a causa, não o sintoma: placeholder em vez de escapar a string; policy em vez de if solto na rota; schema de saída em vez de regex na resposta do LLM.
• Escreva o teste negativo junto com a correção (a entrada maliciosa deve falhar) — é o que impede a regressão.
• Secret encontrado no repositório: rotacione primeiro, depois remova do código e do histórico. Remover sem rotacionar não resolve nada.
• Não "arrume" desabilitando a proteção (CSRF off, verify: false, rejectUnauthorized: false, eslint-disable em regra de segurança). Isso é achado novo, não correção.
• Se o projeto usa a skill git-flow-delivery, a correção segue o fluxo dela (branch, commit com o card, PR). Secret exposto e 🔴 explorável em produção são hotfix.

Para conferir que a revisão não deixou buraco — cada item e onde ele é tratado neste arquivo:

• [ ] Stack detectada; sinais de LLM verificados
• [ ] audit de dependências rodado; secrets procurados (código e histórico)
• [ ] Todas as linhas do mapa de cobertura revisadas — matches confirmados
• [ ] Se há LLM: output handling, prompt injection, agency, RAG e logs checados
• [ ] Cada achado com arquivo:linha, exploração e correção; severidade atribuída
• [ ] Relatório entregue antes de qualquer alteração
• [ ] Correções aprovadas, uma por vez, com teste negativo; secrets rotacionados