Então você entrou no mundo do vibe coding. Subiu uma landing page em 20 minutos, gerou um dashboard na hora do almoço e, honestamente? Parece mágica. Só que tem uma coisa que ninguém menciona nessa festa do desenvolvimento assistido por IA: 45% do código gerado por IA contém vulnerabilidades de segurança. Não é erro de digitação. Quase metade.
Vou te dar um checklist de segurança para vibe coding que você vai realmente usar — 15 passos para pegar o que tem de podre antes que alguém te exploda. Sem enrolação, sem aquela linguagem de RFP corporativo. Só verificações práticas que você consegue rodar antes de apertar o botão de deploy.
Por Que a Maioria dos Vibe Coders Erra na Segurança
Vou ser direto: a velocidade que faz o vibe coding incrível é exatamente o que o torna perigoso. Quando você está subindo features em minutos em vez de dias, revisão de segurança acaba... sendo pulada.
E os assistentes de IA? Eles foram treinados numa mistura de código seguro, tutoriais desatualizados e — sim — algumas respostas terríveis do Stack Overflow lá de 2014. Os modelos não sabem distinguir. Eles geram código que "funciona" mas deixa seu app completamente aberto.
Olha o que aconteceu em 2025:
| Incidente | Impacto | Causa Raiz |
|---|---|---|
| Brecha de Segurança no Lovable | 170+ apps expostos | Credenciais hardcoded no código gerado |
| Deleção de BD no SaaStr | Perda total de dados | Verificações de autenticação insuficientes |
| CVE do CurXecute | Execução remota de código | Input do usuário sem sanitização |
| Exfiltração DNS do Claude | Vazamento de dados | Injeção de dependência maliciosa |
Isso não é hipótese. Aconteceu em projetos reais, construídos por devs exatamente como você. E com a LGPD em vigor no Brasil, um vazamento de dados não é só dor de cabeça técnica — pode virar multa e processo.
O Checklist de Segurança para Vibe Coding em 15 Passos
Vamos lá. Organizei em cinco categorias. Salva esse link nos favoritos — você vai voltar aqui.
Validação de Input (Passos 1-3)
Passo 1: Valide Todos os Inputs do Usuário
A IA confia cegamente no input do usuário. Ela vai gerar formulários que passam valores direto pro banco de dados sem pensar duas vezes.
Verifique cada formulário, campo de busca e parâmetro de URL. Pergunte a si mesmo: O que acontece se alguém digitar <script>alert('hacked')</script> aqui?
Procure padrões assim no seu código gerado:
// 🚨 Dangerous - AI loves generating this const name = req.body.name; db.query(`SELECT * FROM users WHERE name = '${name}'`);
Isso é uma injeção de SQL esperando pra acontecer. Mesmo em projetos só de frontend usando ferramentas como o 0xMinds, você precisa sanitizar antes de enviar pra qualquer backend.
Passo 2: Sanitize os Dados Antes de Renderizar
Esse é o passo de prevenção de XSS. Código React gerado por IA costuma usar dangerouslySetInnerHTML sem entender por que o nome é "dangerous" (perigoso mesmo).
Pesquise no seu projeto por:
dangerouslySetInnerHTMLinnerHTML- Interpolação direta de string no HTML
Se achar, ou remove ou garante que está usando uma biblioteca de sanitização como DOMPurify.
Passo 3: Verifique Vulnerabilidades de XSS
Além dos problemas óbvios com innerHTML, fique de olho em:
- Conteúdo do usuário renderizado sem escape
- Parâmetros de URL exibidos na página
- Valores de formulário refletidos de volta ao usuário
Teste rápido: tente inserir "><img src=x onerror=alert(1)> em qualquer campo de input. Se aparecer um alert, você tem problema.
Autenticação e Autorização (Passos 4-6)
Passo 4: Revise a Lógica de Autenticação
A IA gera código de auth que parece correto, mas frequentemente não está. Já vi formulários de login gerados que:
- Armazenam senhas em texto plano
- Usam validação apenas no lado do cliente
- Criam JWTs sem expiração
- Usam
secret123como chave de assinatura (juro que não tô inventando)
Se estiver construindo fluxos de autenticação, esse é o único lugar onde eu digo: não vibre código aqui. Use bibliotecas estabelecidas como NextAuth, Auth0 ou Clerk. Não vale a aposta.
Passo 5: Verifique as Checagens de Autorização
Autenticação é "quem é você?" Autorização é "o que você pode fazer?"
A IA esquece autorização com frequência impressionante. Ela vai gerar um painel admin acessível a qualquer um que adivinhe a URL. Verifique cada rota e componente:
- Existe uma checagem de role do usuário?
- Um usuário comum consegue acessar funções de admin?
- Os endpoints da API estão protegidos no servidor, e não só escondidos na UI?
Isso está alinhado com as boas práticas de vibe coding — sempre verifique, nunca assuma.
Passo 6: Audite o Manejo de Chaves de API
Esse aqui me dá calafrio toda vez. Assistentes de IA vão colocar suas chaves de API direto no código de frontend sem hesitar:
// 🚨 AI loves doing this const apiKey = "sk-live-abc123xyz789"; fetch(`https://api.example.com?key=${apiKey}`);
Pesquise em todo o projeto por:
- Qualquer string começando com
sk-,api_,key_ - URLs hardcoded com parâmetros de query
- Arquivos
.envcommitados no git
Se você está usando builders de frontend, lembra: qualquer coisa no código do cliente é visível pra qualquer pessoa que abrir o DevTools.
Segurança de Dependências (Passos 7-9)
Passo 7: Cheque Vulnerabilidades nas Dependências
Rode isso antes de cada deploy:
npm audit
A IA gera código com dependências, e essas dependências têm dependências. Em algum lugar nessa árvore, provavelmente tem uma vulnerabilidade.
Para corrigir a maioria dos problemas rapidinho:
npm audit fix
Para projetos sérios, integre Snyk ou Dependabot no seu fluxo. Se usar GitHub, o Dependabot já vem disponível — não tem desculpa pra não ativar.
Passo 8: Remova Pacotes Alucinados
Esse é estranho, mas acontece mais do que você imagina. A IA às vezes inventa pacotes que não existem — ou pior, importa pacotes que existem, mas não são o que ela pensa que são.
Atacantes já começaram a criar pacotes maliciosos com nomes que a IA costuma alucinar. Verifique que cada pacote no seu package.json:
- Realmente existe no npm
- Tem uma quantidade relevante de downloads
- É o pacote que você está imaginando
Se você vê algo como react-utils-helper-pro com 12 downloads no total, isso é red flag gigante.
Passo 9: Atualize Bibliotecas Desatualizadas
Os dados de treinamento da IA têm um cutoff. O código que ela gera pode usar versões de bibliotecas de 2023 com vulnerabilidades conhecidas.
npm outdated
Preste atenção especial em:
- Qualquer pacote com um bump de versão maior disponível
- Pacotes relacionados a segurança (auth, crypto, sanitização)
- Pacotes com CVEs publicados
Prevenção de Exposição de Dados (Passos 10-12)
Passo 10: Revise as Mensagens de Erro
O tratamento de erros gerado por IA costuma expor coisa demais:
// 🚨 Too much information catch (error) { res.status(500).json({ error: error.message, stack: error.stack, query: "SELECT * FROM users WHERE..." }); }
Atacantes adoram mensagens de erro detalhadas. Elas revelam sua stack, estrutura de banco de dados e lógica interna. Em produção, erros devem ser genéricos: "Algo deu errado. Tente novamente."
Passo 11: Cheque os Console Logs em Busca de Dados Sensíveis
Sério. Abre o DevTools e veja o que está sendo logado.
A IA adora console.log pra debug e frequentemente esquece de removê-los. Já vi apps em produção logando:
- Senhas de usuários
- Respostas de API com dados pessoais (CPF, e-mail, telefone)
- Tokens de autenticação completos
- Queries do banco de dados
Pesquise por console.log e revise cada um antes de subir.
Passo 12: Valide as Variáveis de Ambiente
Seu arquivo .env deve conter segredos. Seu código de frontend não deve.
Verifique que:
.envestá no.gitignore- Apenas vars com prefixo
NEXT_PUBLIC_ouVITE_são usadas no lado do cliente - Nenhuma chave sensível está exposta nos bundles do browser
Faça um build e dê um grep no output por qualquer string que pareça uma chave.
Testes e Deploy (Passos 13-15)
Passo 13: Teste os Casos Extremos
A IA gera código para o caminho feliz. Ela raramente considera:
- E se o usuário enviar um formulário vazio?
- E se a API retornar null?
- E se o array estiver vazio?
- E se alguém colar 10MB de texto?
Escreva testes para os casos bizarros. Ou no mínimo, tente quebrar seu próprio app manualmente antes de outra pessoa fazer isso por você.
Passo 14: Rode Ferramentas de Escaneamento de Segurança
Automatize o que der. Aqui estão ferramentas que realmente ajudam:
| Ferramenta | O Que Faz | Custo |
|---|---|---|
| npm audit | Checa vulnerabilidades em dependências | Grátis |
| Snyk | Escaneamento de dependências + código | Plano grátis |
| ESLint Security Plugin | Detecta padrões de código inseguros | Grátis |
| OWASP ZAP | Teste de penetração automatizado | Grátis |
| Semgrep | Análise de código por padrões | Plano grátis |
Um scan rápido de segurança leva 5 minutos. Remediar uma brecha leva semanas — e ainda pode virar autuação da ANPD.
Passo 15: Revise Antes de Fazer o Deploy
Esse é o meta-passo. Antes de apertar o botão de deploy:
- Você passou pelos passos 1-14?
- Você revisou o código gerado, e não apenas testou se funciona?
- Você ficaria tranquilo se um pesquisador de segurança olhasse isso?
Se você está levando vibe coding a sério, considere adicionar um passo de context engineering onde você diz explicitamente pra IA priorizar segurança nas gerações.
Ferramentas de Segurança Recomendadas para Vibe Coders
Você não precisa de um time de segurança. Mas precisa de ferramentas. Aqui está o que eu usaria de verdade:
Para escaneamento de dependências:
npm audit(já vem built-in, use sempre)- Snyk (plano grátis excelente, integra com GitHub e GitLab)
- Socket.dev (especializado em capturar ataques de supply chain)
Para escaneamento de código:
- ESLint com plugins de segurança
- Semgrep (crie regras customizadas para seu projeto)
- SonarQube (se quiser a experiência enterprise completa)
Para proteção em runtime:
- Helmet.js (headers de segurança para Express)
- Headers de Content Security Policy
- Rate limiting em todos os endpoints — especialmente importante se você tem endpoints públicos
O Que Acontece Quando Você Pula o Checklist
Não estou tentando te assustar. Bom, tô um pouco, sim. Mas essa é a realidade:
O incidente de segurança do Lovable afetou 170 apps porque desenvolvedores subiram código gerado por IA sem revisar o tratamento de credenciais. O código "funcionava" — só que também expunha os dados de todos os usuários.
Esse é um dos principais erros do vibe coding que você precisa evitar. A velocidade da geração por IA cria pressão para subir rápido. Mas subir código vulnerável rápido é pior do que subir código seguro devagar. E se você tem usuários brasileiros, um vazamento pode te colocar em rota de colisão com a LGPD — não é papo de advogado, é realidade do mercado.
Suba Código com Consciência
Minha visão: segurança em vibe coding não é sobre diminuir o ritmo. É sobre incorporar o checklist no seu fluxo para que a segurança aconteça de forma automática.
Imprime esse checklist. Cola ele do lado do seu monitor. Passa por ele toda vez que for fazer deploy de código gerado por IA. Leva 15 minutos e pode te salvar de ter que explicar pros seus usuários por que os dados deles estão circulando em algum canal do Telegram.
O checklist de segurança para vibe coding deixou de ser opcional. Com 45% do código de IA contendo falhas, a questão não é se você vai gerar código vulnerável — é se você vai pegar isso antes que alguém de fora pegue primeiro.
Agora vai lá proteger seus apps. Você do futuro (e seus usuários) vão agradecer.
Quer praticar vibe coding com segurança?
Try this prompt⌘+Enterto launch
