Checklist de segurança antes de lançar um app vibe-coded

Busque no bundle: grep -r "sk-" .next/static/ e grep -r "eyJ" .next/static/ após um build local. Qualquer resultado é crítico.

Execute: git log --all --full-history -- .env .env.local .env.production — se retornar commits, o arquivo foi commitado.

Confirme que .gitignore contém: .env, .env.local, .env.production, .env.*.local

Banco de dados, Stripe, OpenAI e outros serviços devem ter chaves separadas por ambiente. Chave de dev comprometida não pode afetar produção.

No Vercel/Netlify/Railway: confirme que todas as variáveis estão configuradas em Settings → Environment Variables — não apenas localmente.

Em next.config.ts, confirme: productionBrowserSourceMaps: false. Source maps em produção expõem o código-fonte original.

No Supabase SQL Editor: SELECT tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; — todos devem retornar true.

No Supabase Dashboard → Authentication → Policies: cada tabela deve ter políticas explícitas para cada operação usada pelo app.

Busque "service_role" no bundle: grep -r "service_role" .next/static/ — deve retornar vazio. A service_role ignora o RLS.

A URL de conexão do banco deve incluir ?sslmode=require. Verifique nas variáveis de ambiente do provedor de deploy.

Dev e produção devem usar bancos separados. Acesso ao banco de produção deve ser restrito e auditado.

Em uma aba anônima, abra o console e execute: fetch('/api/seu-endpoint', { method: 'POST', body: JSON.stringify({}) }). Deve retornar 401, não 200.

Revise cada API route: o userId/ownerId usado nas queries deve ser session.user.id, nunca request.body.userId.

Qualquer rota /api/admin/* deve verificar tanto a autenticação quanto a role do usuário antes de executar.

No middleware.ts: confirme que nenhuma rota protegida está comentada ou tem condição de bypass ativa. Busque por "TODO" e "temporário".

Sessões não devem durar indefinidamente. Configure JWT expiry ou session maxAge de acordo com a sensibilidade dos dados.

Logout deve invalidar o token/sessão no servidor, não apenas no cliente. Tokens localStorage deletados do cliente ainda funcionam se não invalidados.

Inspecione as API routes em busca de Access-Control-Allow-Origin: * — substitua por lista explícita das origens do seu domínio.

Cada API route deve validar tipo, formato e limites dos dados recebidos antes de usar. Strings sem limite de tamanho são um vetor de DoS.

Rotas que chamam OpenAI, Stripe ou outros serviços pagos devem ter rate limiting por IP ou por usuário autenticado.

Webhooks do Stripe, GitHub e outros devem verificar a assinatura HMAC do payload. Sem isso, qualquer pessoa pode enviar eventos falsos.

Em produção, mensagens de erro devem ser genéricas para o cliente. Stack traces nunca devem aparecer em respostas de API.

F12 → Network → clique no documento HTML → Response Headers. Verifique presença de Content-Security-Policy. Ausente = XSS irrestrito.

Response headers deve conter Strict-Transport-Security: max-age=... — força HTTPS e protege contra downgrade attacks.

Protege contra clickjacking. Deve estar X-Frame-Options: DENY ou frame-ancestors 'none' no CSP.

Previne que o browser interprete arquivos com tipo MIME incorreto. Simples de adicionar no next.config ou no servidor.

Verifique com testssl ou use o scanner do Defenty. TLS 1.0 e 1.1 são obsoletos e devem estar desabilitados.

Se o projeto não é open source, o repositório deve ser privado. Repositórios públicos expõem lógica de negócio e podem conter secrets históricos.

No Vercel: configure variáveis de ambiente diferentes para Preview vs Production. Previews não devem ter acesso ao banco de produção.

Revise quem tem acesso ao repositório, ao Vercel/Netlify e ao Supabase Dashboard. Remova acessos de colaboradores que saíram do projeto.

Execute npm audit no diretório do projeto. Vulnerabilidades críticas e altas devem ser corrigidas antes do lançamento.