Segurança em Vibe Coding

Antes de anunciar seu lançamento, execute estas 69 verificações. Elas correspondem aos padrões exatos por trás da CVE RLS do Lovable (CVE-2025-48757, 170+ apps, 2025), do vazamento do Moltbook (1,5M de tokens de API, fev 2026) e da violação da plataforma Lovable em abril de 2026 (código-fonte + chaves de serviço de projetos de outros usuários, expostos por ~2,5 meses).

Quer o kit completo? 50 skills de auditoria, 15 .cursorrules, 1 configuração MCP + 4 receitas de CLI, 30 prompts de revisão adversarial, 10 estudos de caso. Instalação em 5 minutos. US$ 10 fixo.

→ rishabhvaai.gumroad.com/l/plddbd

---

Em uma auditoria publicada em outubro de 2025, a Escape.tech examinou 5.600 aplicativos reais gerados por IA em 14.600 ativos (metodologia). Eles relataram 2.038 vulnerabilidades críticas, mais de 400 segredos vazados e 175 instâncias de PII exposta em 1.400 desses aplicativos (descobertas). Os segredos saíram direto dos bundles de frontend: chaves Stripe, OpenAI e Supabase paradas em JavaScript no lado do cliente. Não melhorou desde então: o relatório de 2026 da GitGuardian contou 28,6 milhões de novos segredos no GitHub público em 2025 (+34% A/A), segredos de serviços de IA subiram 81%, e commits coautorados por agentes de codificação vazando segredos a aproximadamente 2x a linha de base humana. Esta é uma checklist de 69 itens específicos e testáveis. Cada um corresponde a um padrão real de incidente. Se você conseguir marcar todos os 69, publique. Se não conseguir, corrija o que está bloqueando você.

Não é um SaaS. Não é um scanner. É uma lista simples que você percorre antes de fazer push para produção.

---

A Checklist de Segurança Pré-Lançamento de 69 Pontos

Você está a 30 minutos de publicar. Pare. Execute isto primeiro.

Somente a vulnerabilidade RLS do Lovable (CVE-2025-48757, 2025, CVSS 9.3) expôs mais de 170 aplicativos em produção. O Moltbook expôs 1,5 milhão de tokens de API em fevereiro de 2026 — consultáveis com um único curl. Esses não foram casos extremos. Foram lançamentos mainstream.

Esta checklist agrupa 69 itens específicos e testáveis em autenticação, segredos, APIs, bancos de dados, frontend, IA/LLM, ferramentas de agentes e deployment. Se você não conseguir marcar todos os 69, não publique.

---

Autenticação (8 itens)

• 1. A Segurança em Nível de Linha (RLS) do banco de dados está habilitada em todas as tabelas do seu banco de dados.
• 2. Existem políticas de RLS para toda tabela e todo papel (anon, authenticated, service_role).
• 3. Os tokens JWT são validados no lado do servidor em toda rota de API protegida (nunca confie no frontend para validar autenticação).
• 4. As sessões são rotacionadas ou invalidadas após o login (proteção contra CSRF + fixação de sessão).
• 5. Os magic links (autenticação sem senha) são de uso único, expiram em menos de 15 minutos e estão vinculados ao IP do usuário ou à impressão digital do dispositivo.
• 6. Você não consegue atualizar ou excluir usuários, pedidos ou registros sensíveis com base apenas em IDs fornecidos pelo usuário. Teste: tente atualizar o registro de outro usuário alterando o ID na requisição.
• 7. Os tokens CSRF são validados em requisições que alteram estado (POST, PUT, DELETE) via double-submit cookie ou SameSite=Strict.
• 8. Os cookies de sessão têm as flags HttpOnly, Secure e SameSite=Strict configuradas.

Segredos e Ambiente (7 itens)

• 9. Sem segredos em variáveis NEXT_PUBLIC_*, arquivos .env de Vue/React ou strings hardcoded. Faça grep de NEXT_PUBLIC_ e audite todas as variáveis.
• 10. .env, .env.local, .env.*.local estão no .gitignore e nunca são commitados. Verifique o histórico do git: git log --all -p | grep -i "api_key\|secret".
• 11. A chave service_role do Supabase está SOMENTE no .env do lado do servidor (Node, Python, Go, etc.), nunca em bundles de frontend ou .env.local. A chave service_role contorna a RLS completamente — um vazamento é leitura/gravação total em todas as tabelas.
• 12. Chaves Stripe: chave pública em NEXT_PUBLIC_*, chave secreta somente no servidor, assinatura de webhook verificada.
• 13. Chaves de API da OpenAI, Anthropic e xAI nunca estão no código do frontend; sempre são proxy via sua API.
• 14. Sem chaves de API hardcoded, URLs de banco de dados ou credenciais em qualquer lugar do código-fonte (incluindo comentários e código não utilizado).
• 15. Os segredos são rotacionados após o lançamento ou se forem expostos no histórico do código-fonte.

Hardening de API (10 itens)

• 16. Rate limiting está ativo em /api/auth/*, /api/login, /api/register. Teste: 100 requisições/minuto devem retornar 429.
• 17. Todas as entradas de usuário em /api/* são validadas com Zod, Yup ou similar antes de tocar o banco de dados. Nenhum req.body cru é passado para consultas.
• 18. Sem mass assignment: o usuário não pode definir admin=true, role=admin ou outros campos sensíveis via POST.
• 19. As assinaturas de webhook são verificadas (compare o header de assinatura HMAC-SHA256 ao valor esperado usando comparação em tempo constante).
• 20. O CORS não está definido como *. As origens permitidas são hardcoded e não incluem localhost em produção.
• 21. As consultas SQL usam apenas statements parametrizados. Sem concatenação de string de entrada do usuário em SQL.
• 22. As consultas NoSQL (MongoDB, Firebase, etc.) não concatenam entrada do usuário em filtros ou seletores.
• 23. Os uploads de arquivos são validados (tipo MIME + tamanho do arquivo), armazenados fora da raiz web e renomeados para prevenir path traversal.
• 24. Os redirecionamentos após login estão na whitelist. Não é possível redirecionar para um domínio externo via open redirect.
• 25. A API não faz requisições externas não validadas. Garanta que URLs usadas em requisições no lado do servidor venham da sua allowlist, não de entrada do usuário (prevenção de SSRF).

Banco de Dados (6 itens)

• 26. A RLS é APLICADA em todas as tabelas. O papel anon não pode fazer SELECT/INSERT/UPDATE/DELETE em nenhuma tabela sem uma política explícita concedendo isso.
• 27. O papel anon público tem zero permissões padrão. As políticas concedem apenas o necessário. Somente leitura em listas públicas, nunca gravação.
• 28. A chave service-role é usada SOMENTE no código do lado do servidor. Verifique: grep -r "service_role" src/. Deve retornar zero resultados em arquivos de frontend.
• 29. Isolamento de dados do usuário: as consultas sempre filtram por auth.uid() ou team_id. Nenhuma consulta retorna todos os registros de todos os usuários.
• 30. Soft deletes (flag is_deleted) ou tabelas de arquivamento previnem perda acidental de dados. Hard deletes são registrados com ator + timestamp.
• 31. Os backups do banco de dados existem e são testados. Você verificou que consegue restaurar a partir de um backup antes deste lançamento.

Frontend (8 itens)