launch-audit

Launch Audit

Audite um app para que ele não seja hackeado ou processado. O trabalho é dividido em quatro arquivos de referência — leia apenas os (e as seções) que se aplicam ao stack à sua frente:

Arquivo	Use para
references/prelaunch-checklist.md	A lista de verificação de 20 itens (vai/não vai). Comece aqui para uma verificação rápida.
references/security.md	Revisão completa de segurança: segredos, autenticação, controle de acesso, injeção, navegador/transporte, supply chain, recursos de IA, operações.
references/legal-compliance.md	Políticas, consentimento, direitos de privacidade, marketing honesto, crianças, e-mail, propriedade intelectual, acessibilidade.
references/stack-notes.md	Armadilhas específicas de plataforma: Supabase, Firebase, Next.js, Express, Django, Rails, Laravel, mobile, Stripe, apps LLM.

Cada item da lista de verificação tem um ID (SEC-*, LEG-*, A11Y-*). Use esses IDs no relatório para que os achados sejam rastreáveis.

Escolha o modo

• Rápido ("checklist de lançamento", "estou pronto para lançar?", pouco tempo) → apenas prelaunch-checklist.md.
• Segurança ("auditoria de segurança", "evitar ser hackeado", "isso é seguro?") → security.md + seções relevantes de stack-notes.md.
• Jurídico ("evitar ser processado", "GDPR", "banner de cookies", "política de privacidade") → legal-compliance.md.
• Completo (padrão quando o usuário apenas diz "audite meu app" antes do lançamento) → todos os anteriores.

Fluxo de trabalho

1. Escopo — principalmente automático

Descubra estas informações a partir do repositório antes de perguntar qualquer coisa:

• Stack: framework, linguagem, backend/BaaS (Supabase, Firebase, servidor próprio), banco de dados, provedor de autenticação, hospedagem, web vs mobile vs ambos. Olhe package.json, lockfiles, requirements.txt/pyproject.toml, Gemfile, composer.json, pubspec.yaml, supabase/, firebase.json, vercel.json, Dockerfile, arquivos de CI.
• Inventário de dados: quais dados pessoais são coletados (formulários, campos de cadastro, analytics), onde são armazenados, quais SDKs/serviços de terceiros os recebem (analytics, anúncios, relatórios de falhas, pagamentos, e-mail, APIs de IA).
• Dinheiro: pagamentos, assinaturas, testes gratuitos, compras no aplicativo.
• Superfície: páginas públicas, rotas de API, server actions, funções de edge/cloud, webhooks, áreas administrativas, uploads de arquivos, recursos de IA/LLM.

Em seguida, pergunte ao usuário — em uma mensagem, apenas o que o código não pode dizer: mercados-alvo (UE/Reino Unido/EUA/Brasil/outro), se menores de idade podem usar, a URL ativa ou de staging (se houver), e se ele quer correções aplicadas ou apenas um relatório.

Se o usuário estiver indisponível, assuma UE + EUA, apenas adultos, relatório primeiro, e diga isso no início do relatório.

2. Passagem automatizada

python3 scripts/scan.py <caminho-do-repositorio>              # árvore de trabalho
python3 scripts/scan.py <caminho-do-repositorio> --history    # também verifica histórico do git por segredos
python3 scripts/check_live.py https://staging.exemplo.com   # cabeçalhos ativos, cookies, CORS, arquivos expostos

Ambos os scripts usam apenas a biblioteca padrão do Python 3. check_live.py envia algumas requisições GET inofensivas — execute-o apenas contra sites que o usuário possui ou está autorizado a testar.

Execute também o auditor de dependências do ecossistema quando disponível (npm audit, pnpm audit, pip-audit, osv-scanner, bundle audit, composer audit, cargo audit); o scan.py exibe os comandos certos para os manifestos que encontrar.

Trate a saída dos scripts como pistas, não vereditos. Confirme cada sinal lendo o código; descarte falsos positivos. Uma varredura limpa não significa seguro: os bugs mais prejudiciais (controle de acesso quebrado, verificações ausentes no servidor, vazamentos entre tenants) são bugs de lógica que apenas a leitura encontra.

3. Revisão manual

Leia, nesta ordem:

1. Configuração de autenticação e middleware; como o servidor descobre quem está chamando.
2. Todas as rotas de API, server actions, funções de edge/cloud e handlers de webhook.
3. Regras de acesso ao banco de dados: políticas RLS, regras do Firebase, escopos ORM, privilégios de usuário no BD.
4. Tudo que constrói SQL, comandos shell, HTML, caminhos de arquivos ou URLs a partir de entrada.
5. Handlers de upload e download de arquivos.
6. Recursos de IA/LLM: qual texto não confiável chega ao modelo e quais ferramentas o modelo pode chamar.
7. Páginas legais, banner de cookies, fluxos de cadastro e checkout, textos de marketing, e-mails.

Para cada endpoint, responda a quatro perguntas: Quem está chamando? Isso é verificado no servidor? O registro pertence a ele (ou ao seu tenant)? Quais campos eles podem escrever? Um "não" ou "não sei" é um achado.

4. Classifique

Status por item: FAIL · WARN · PASS · MANUAL (precisa de um humano: revisão de texto legal, exercício de restauração de backup, advogado) · N/A. Nunca marque PASS para algo que você não verificou de fato — use MANUAL.

Severidade para falhas:

• Crítico — explorável agora ou já exposto: segredo ativo no repositório/pacote/histórico, banco de dados legível ou gravável sem autenticação, RLS desabilitado em uma tabela com dados de usuário, bypass de autenticação, IDOR em dados pessoais, injeção SQL/comandos, RCE.
• Alto — sério com uma pequena pré-condição: falta de rate limit no login/reset, XSS armazenado, falta de verificação de assinatura de webhook, hash de senha fraco, CORS permissivo com credenciais, modo debug ativo em produção, sem backups. Jurídico: um requisito obrigatório para um mercado declarado que está faltando (sem política de privacidade enquanto coleta dados pessoais; rastreamento não essencial antes do consentimento na UE/Reino Unido; sem exclusão de conta em um app da loja).
• Médio — lacunas de defesa em profundidade: cabeçalhos de segurança ausentes, erros detalhados, sem log de auditoria, dependências desatualizadas não exploráveis. Jurídico: conteúdo de política incompleto, problemas de UX de consentimento, falhas de acessibilidade.
• Baixo — higiene e polimento.

5. Relatório

Preencha templates/report.md. Lide com o veredito:

• 🔴 Não pronto — qualquer Crítico, ou Itens Altos que tocam dados pessoais ou dinheiro.
• 🟡 Pronto com correções — Altos/Médios com um plano para corrigir esta semana.
• 🟢 Pronto — nenhum Crítico/Alto; Médios registrados.

Cada achado: ID, severidade, evidência (arquivo:linha ou URL + cabeçalho), uma linha sobre o risco, uma correção concreta (código quando for curto). Agrupe por severidade, não pela ordem da checklist. Mantenha itens PASS em uma tabela compacta.

Nunca cole um segredo completo no relatório ou no chat. Mostre os primeiros 4 caracteres e mascare o resto (sk_l****).

6. Corrigir

Ofereça-se para corrigir na ordem de severidade. Edite código apenas quando o usuário pedir correções ou concordar. Após corrigir, execute novamente scan.py (e check_live.py após o deploy) e atualize o relatório.

Segredo vazado, sempre nesta ordem: revogue/gire a chave no provedor → remova-a do código e mova para variáveis de ambiente do servidor → elimine-a do histórico do git (git filter-repo ou BFG) e force-push. Apenas eliminar não adianta: a chave já está em clones, forks, logs de CI e caches.

Regras básicas

• Não é aconselhamento jurídico. Você pode redigir políticas de privacidade, termos, políticas de cookies e políticas de reembolso, mas um rascunho deve descrever o que o app realmente faz (os dados, SDKs e processadores encontrados nas etapas 1–3), não deve ser copiado de outra empresa e deve ser sinalizado para revisão por um advogado para os mercados-alvo.
• Apenas defensivo. Teste apenas sistemas que o usuário possui ou está autorizado a testar. Explique vulnerabilidades e correções; não construa explorações funcionais contra terceiros.
• Sem código, só uma URL? Execute check_live.py, inspecione o site (links legais no rodapé; se rastreadores disparam antes do consentimento; se "Rejeitar" é tão fácil quanto "Aceitar"; formulários e checkout) e marque itens de nível de código como MANUAL.
• Apps mobile: qualquer coisa enviada no binário do app é pública. Segredos em um app mobile são segredos vazados.
• Prefira correções nativas da plataforma (políticas RLS, middleware do framework, configurações do provedor) em vez de soluções artesanais.