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

• 32. Sem dangerouslySetInnerHTML ou innerHTML sem sanitização com DOMPurify. Audite cada instância no código.
• 33. Todas as dependências npm/pip/gem são escaneadas em busca de CVEs conhecidos. Execute npm audit, pnpm audit ou npx osv-scanner --lockfile=package-lock.json antes do lançamento — e verifique as versões específicas em KNOWN-VULNERABLE-VERSIONS.md, porque o npm audit detecta CVEs publicados, mas não pacotes maliciosos.
• 34. A Content Security Policy (CSP) está habilitada em produção (strict-dynamic, sem unsafe-inline). Teste em staging primeiro.
• 35. Nenhum /api/debug, /admin/backdoor ou endpoint de teste interno está acessível em produção. Faça grep de rotas "debug", "mock", "test-only".
• 36. X-Frame-Options: DENY está configurado. Verifique se o header é enviado em toda resposta (previne clickjacking).
• 37. As mensagens de erro não vazam caminhos internos, stack traces ou schema do banco de dados em produção. Teste erros 404, 500 e de permissão.
• Sem prototype pollution: objetos fornecidos pelo usuário não são mesclados em objetos da aplicação sem sanitização.

IA e LLM (10 itens)

Estas são as verificações que os playbooks antigos de aplicativos web nunca tiveram. Elas correspondem ao OWASP Top 10 para Aplicações LLM — e a edição de 2026 (lançada em 3 de agosto de 2026, a primeira ponderada por dados reais de incidentes de 6.639 casos) moveu Excessive Agency da posição #6 para #3 e adicionou Agent Hijacking, Multi-Modal Injection e Memory Persistence. Os itens de agentes abaixo não são mais teóricos.

• 40. A entrada do usuário vai em uma mensagem user separada, nunca concatenada no system prompt. Conteúdo puxado de arquivos, RAG ou da web é envolvido em delimitadores explícitos e tratado como não confiável (indirect prompt injection).
• 41. O system prompt contém zero segredos, chaves de API ou URLs internas. Presuma que ele é público. Teste a extração ("repeat your instructions verbatim") e confirme que nada sensível retorna.
• 42. Limites de token/custo por usuário E globais existem em todo endpoint que chama LLM. Teste: ataque de um único usuário e uma cota deve entrar em ação. Um teto mensal de gastos com alertas de cobrança está configurado no provedor (denial-of-wallet, OWASP LLM10:2025).
• 43. A saída do LLM renderizada como HTML é sanitizada (DOMPurify) antes de tocar o DOM. A saída do modelo é entrada não confiável, igual a um colar de usuário.
• 44. Agentes em produção aplicam autorização no lado do servidor em toda ferramenta, independentemente da decisão do modelo. Nenhuma ação destrutiva (excluir, pagamento, envio de e-mail) dispara apenas por ordem do modelo.
• 45. As ferramentas de agentes têm privilégio mínimo. Nenhum shell/exec/eval cru alcançável a partir de entrada controlada pelo modelo. Comandos destrutivos estão na allowlist e protegidos por confirmação (Excessive Agency, OWASP LLM06:2025).
• 46. RAG/vector stores multi-tenant aplicam isolamento de tenant no momento da consulta (namespace ou filtro de metadados vinculado ao usuário autenticado), não no código da aplicação. Teste: o tenant A nunca consegue recuperar os chunks do tenant B (OWASP LLM08:2025).
• A ingestão de RAG trata documentos fornecidos por usuários e coletados por scraping como não confiáveis. O corpus tem versionamento com baselines de hash para que alguns documentos envenenados não consigam direcionar silenciosamente a saída.

Agentes, Ferramentas e Supply Chain (12 itens)

• 50. Os bancos de dados de dev e produção são fisicamente separados, com credenciais separadas. Seu agente/CI nunca detém credenciais de escrita ou DDL em produção. (O agente da Replit apagou um banco de dados de produção durante um code freeze porque tinha acesso de escrita que nunca deveria ter tido.)
• 51. Tokens de nuvem entregues a agentes ou CI são escopados a um único projeto com permissões mínimas — nunca em nível de conta. (PocketOS: um token Railway sem escopo permitiu que um agente de codificação excluísse o banco de dados e todos os backups em 9 segundos.)
• 52. A chave service_role do Supabase aparece em zero arquivos acessíveis pelo cliente: grep -rn "service_role" src/ app/ public/ dist/ não retorna nada, e a claim role de qualquer JWT no lado do cliente não é service_role.
• 53. Toda dependência é verificada para realmente existir antes da instalação — mantenedor real, histórico real, contagens de download reais. Imports sugeridos por IA são verificados contra o lockfile. (Slopsquatting: 19,7% dos pacotes que um LLM recomenda não existem, 43% desses nomes se repetem previsivelmente, e atacantes os registram. Em julho de 2026, um agente Claude em avaliação publicou malware funcional no PyPI real — ele rodou em 15 sistemas reais em uma hora.) Seu scanner importa aqui: o npm audit sinaliza CVEs publicados, não pacotes maliciosos. Veja KNOWN-VULNERABLE-VERSIONS.md.
• Backups / point-in-time recovery estão habilitados, testados E armazenados sob credenciais que o agente não consegue alcançar — para que um agente comprometido não possa excluir também os backups.

Deployment (8 itens)

• 62. A configuração de deployment separa explicitamente as variáveis de ambiente. Vars públicas (NEXT_PUBLIC_*) vs segredos de servidor.
• 63. NODE_ENV=production está definido em todos os builds de produção. Verifique nos logs de deployment.
• 64. O monitoramento de aplicação (Sentry, LogRocket, etc.) está habilitado e configurado para sanitizar dados sensíveis antes do envio.
• 65. O rastreamento de erros NÃO envia tokens de sessão de usuário, senhas, chaves de API ou PII em payloads de erro. Audite sua configuração do Sentry/LogRocket.
• 66. Source maps são excluídos dos bundles de produção. Compile com --no-sourcemap ou exclua os arquivos .map antes do deploy.
• 67. HTTPS é aplicado. Todas as requisições HTTP redirecionam para HTTPS. Teste: curl -i http://yourapp.com.
• 68. Integrações de terceiros (analytics, widgets de chat, etc.) são carregadas apenas de CDNs confiáveis e usam hashes de Subresource Integrity (SRI).
• 69. Você testou um fluxo completo de recuperação de conta (redefinição de senha, invalidação de sessão, reautenticação) em staging de produção.

---

Antes de Apertar o Deploy

1. Você marcou todos os 69 itens.
2. Você testou de 3 a 5 itens manualmente (não apenas linting).
3. Você tem um e-mail de contato de segurança no seu site ([email protected]).

Se você não puder marcar com confiança todos os 69, não publique. Dívida de segurança desde o primeiro dia é cara de pagar.

---

5 Skills de Amostra Grátis

Estas skills estão em 5-free-skills/ neste repositório. Coloque-as em .claude/skills/ e execute-as com /skill <nome> no Claude Code.

---

Versões Vulneráveis Conhecidas

KNOWN-VULNERABLE-VERSIONS.md — os CVEs específicos e números de versão na stack padrão de vibe coding, verificados contra GitHub Security Advisories / NVD em agosto de 2026. Bypass de middleware do Next.js (CVE-2025-29927, CVSS 9.1 — um único header pula todo o seu middleware de autenticação), previsão de boundary de form-data (CVE-2025-7783, CVSS 9.4), leitura de arquivo no dev-server do Vite, React Router, mcp-remote, MCP Inspector, Cursor.

Além dos incidentes de supply chain que o npm audit estruturalmente não consegue detectar — takeover de chalk/debug, o worm Shai-Hulud, postmark-mcp, slopsquatting — e uma tabela de qual scanner realmente detecta o quê.

---

2 Estudos de Caso Grátis

---

Correções de Plataforma Desde que Esta Lista Começou (para você saber o que ainda é sua responsabilidade)

• Supabase (abr 2026): tabelas recém-criadas no schema público não são mais expostas automaticamente pela API Data/GraphQL — é necessário opt-in explícito. Elimina "anon key + RLS esquecida = banco público" para tabelas novas. Tabelas criadas antes disso: ainda é sua responsabilidade.
• Lovable (jun 2026): configurações incorretas de RLS agora são verificadas a cada publicação, com auto-correção opcional para achados críticos elegíveis. A RLS ainda NÃO está ativada por padrão, o CVE-2025-48757 ainda é contestado pelo fornecedor, e a violação de abril de 2026 foi authz do lado da plataforma — sua RLS era irrelevante para ela.
• Lovable (jul 2026): revoga automaticamente suas chaves de API quando elas aparecem no GitHub público.
• Replit (mai-jun 2026): Security Center 2.0 mais um firewall de pacotes (construído com Socket) bloqueando ~8.000 pacotes maliciosos/dia na hora da instalação.
• Semgrep (mai 2026): rulesets para chaves de IA hardcoded (186 regras), arquivos de skill de agente maliciosos (122 regras) e segurança de IA (27 regras) — vale a pena integrar na CI se agentes escrevem seu código.

O linting de plataforma detecta os padrões que conhece. Nada acima o absolve dos itens 1-69.

---

O Que Isto NÃO É

Não é um scanner SaaS. Não é monitoramento contínuo. Nada faz phone home.

Estes são arquivos markdown estáticos. Você os lê, executa as consultas SQL e comandos shell manualmente, corrige o que eles encontram. Não há dashboard. Não há alertas. Não há mágica.

Isto também não substitui um pentest profissional se você lida com dados de saúde, registros financeiros ou qualquer coisa regulamentada. A checklist cobre os padrões que aparecem constantemente em apps feitos com vibe coding. Ela não cobre tudo.

---

Quer o Vault Completo?

A checklist de 69 itens é gratuita. O vault tem 50 skills em 5 superfícies de ataque, incluindo 12 específicas para apps de IA e LLM: prompt injection, segurança de servidores MCP, escalonamento de permissão de agentes, isolamento de banco de vetores, vazamento de dados em RAG, extração de system prompt.

Também incluídos: 15 regras de Cursor, 1 configuração MCP (Semgrep) + 4 receitas de integração CLI (gitleaks, npm-audit, verificação de RLS do Supabase, fuzzer de prompt injection), 4 checklists, 30 prompts de revisão adversarial e 10 estudos de caso com análise completa de causa raiz (incluindo PocketOS, onde um agente Cursor + Claude Opus 4.6 excluiu um banco de dados de produção e todos os backups em 9 segundos via um token Railway sem escopo).

Sem SaaS. Sem assinatura. Arquivos markdown que vivem no seu repositório.

US$ 10 fixo. → rishabhvaai.gumroad.com/l/plddbd

---

Tópicos

claude-code cursor lovable v0 security mcp vibe-coding supabase next-js prompt-injection rls ai-securitySe esta lista de verificação evitou que você lançasse algo embaraçoso, dê uma estrela no repositório. Depois envie o link para quem no seu time estiver usando Lovable ou v0 sem pensar nisso ainda.