Vibe Coding e Segurança: Riscos Reais e Checklist para Apps Feitos com IA

Vibe coding é ruim? Não por si só. Descrever o que você quer e deixar uma IA escrever o código é, de fato, um jeito mais rápido de construir software. O ruim é colocar esse código na frente de usuários reais sem ninguém revisar, porque as ferramentas de IA otimizam para o código funcionar, não para ser seguro. Neste guia você vai ver onde essa lacuna aparece, com exemplos concretos, e um checklist de segurança para vibe coding para rodar antes do lançamento.

O termo foi popularizado por Andrej Karpathy em fevereiro de 2025, quando descreveu "um novo tipo de programação que eu chamo de vibe coding, em que você se entrega totalmente às vibes, abraça o exponencial e esquece que o código existe". Esquecer que o código existe tudo bem num projeto descartável. É exatamente o problema quando esse projeto guarda dados de clientes.

O lado bom do vibe coding

Antes de falar de riscos, vale ser justo. Programar com Cursor, Claude Code, Lovable, Bolt, v0 ou Replit tem vantagens reais:

• Velocidade. Um protótipo funcionando em horas, não semanas. O founder valida a ideia antes de contratar um time.
• Acesso. Designers, product managers e especialistas do negócio conseguem criar as ferramentas que antes precisavam pedir.
• Menos boilerplate. Devs experientes pulam o CRUD repetitivo, os formulários e o código de cola, e focam no que é difícil.
• Iteração rápida. Mudar um fluxo é um prompt, não uma sprint.

Nada disso é problema de segurança. O problema é o que se perde no caminho: o code review, o dev sênior que percebe uma chave no arquivo errado, o ambiente de staging, o momento em que alguém pergunta "quem pode chamar este endpoint?".

O que dizem os dados

Não é só impressão. Alguns números que vale conhecer:

• Código inseguro é comum. O GenAI Code Security Report 2025 da Veracode testou código de mais de 100 modelos de linguagem em tarefas de Java, JavaScript, Python e C#, e 45% das amostras falharam nos testes de segurança e introduziram vulnerabilidades do OWASP Top 10.
• Modelos inventam pacotes. O artigo "We Have a Package for You!", apresentado no USENIX Security 2025, gerou 576.000 amostras de código com 16 modelos e descobriu que 19,7% dos pacotes recomendados não existiam. Um atacante que registra um desses nomes executa código em toda máquina que instalar o pacote.
• Apps reais ficaram expostos. O CVE-2025-48757 descreveu projetos gerados pelo Lovable com políticas de Row Level Security insuficientes, que permitiam a atacantes não autenticados ler ou escrever tabelas do banco. O pesquisador que reportou encontrou mais de 170 apps afetados.

Os riscos de segurança do vibe coding que aparecem sempre

1. Segredos hardcoded

A IA coloca a chave onde o código precisa dela. Se for um componente React, a chave vai para o navegador de cada visitante. Se for um arquivo de configuração, vai parar no git, e apagar depois não remove do histórico.

// lib/ai.ts (importado por um client component)
const openai = new OpenAI({ apiKey: "sk-proj-..." });

// next.config.js
env: { NEXT_PUBLIC_STRIPE_SECRET: process.env.STRIPE_SECRET_KEY }

Tudo com o prefixo NEXT_PUBLIC_ (ou VITE_ no Vite) entra no código do cliente. Segredos ficam em código que roda só no servidor, e qualquer chave que já passou por um navegador ou por um commit precisa ser rotacionada, não basta apagar. Na nossa comparação de ferramentas de detecção de segredos mostramos como varrer todo o histórico do git, e um secret scanner pode fazer isso a cada push.

2. Endpoints sem autenticação

// app/api/orders/route.ts
export async function GET() {
  const orders = await db.order.findMany();
  return Response.json(orders); // todos os pedidos, para qualquer um
}

O prompt foi "mostre a página de pedidos". O modelo fez funcionar. Ninguém perguntou quem deveria ver.

3. IDOR: o bug que parece certo

// app/api/invoices/[id]/route.ts
export async function GET(req: Request, { params }) {
  const session = await auth();
  if (!session) return new Response("Unauthorized", { status: 401 });
  const invoice = await db.invoice.findUnique({ where: { id: params.id } });
  return Response.json(invoice); // não verifica se invoice.userId === session.user.id
}

Existe uma checagem de login, então passa numa revisão rápida. Mas qualquer usuário logado pode percorrer IDs e ler as faturas de todo mundo. É uma vulnerabilidade IDOR, parte de broken access control, que lidera o OWASP Top 10. A correção é restringir a query: where: { id: params.id, userId: session.user.id }.

4. Defaults inseguros

Os modelos escolhem o que faz o erro sumir. Um erro de CORS vira Access-Control-Allow-Origin: * com credenciais. Um cookie que não funciona vira um cookie sem Secure. Um crash vira um stack trace devolvido ao cliente. Cada item é pequeno; juntos, deixam qualquer outro bug mais fácil de explorar.

5. Pacotes alucinados e typosquatting

Quando o modelo sugerir um npm install ou pip install, confira se o pacote existe, se é o que você queria e se tem mantenedor e histórico reais. Atacantes publicam pacotes com os nomes que os modelos costumam inventar (às vezes chamado de slopsquatting) e com nomes a uma tecla de distância dos populares. Fixe versões e commite o lockfile.

6. Chaves do Supabase expostas e Row Level Security

O Supabase é o backend padrão de muitos apps feitos com vibe coding, e a documentação é direta: uma tabela em um schema exposto sem RLS pode ser lida e escrita por qualquer role com permissão sobre ela. Só a publishable key (ou a anon key legada) é feita para o navegador, e ela só é segura porque o RLS limita o que ela alcança. Uma secret key ou service_role ignora o RLS e nunca deve sair do servidor.

alter table public.invoices enable row level security;

create policy "owners read their invoices"
  on public.invoices for select
  using ( auth.uid() = user_id );

Falamos de políticas em detalhe no guia de Supabase RLS.

Quando o vibe coding tudo bem e quando é arriscado

Checklist de segurança para vibe coding

Rode antes de compartilhar o link, e de novo antes de começar a cobrar.

Segredos

• Nenhuma API key, token ou senha no código-fonte ou no bundle do cliente.
• Nenhum .env no git, e o histórico inteiro varrido, não só o último commit.
• Toda chave que já ficou exposta foi rotacionada.

Autenticação e autorização

• Cada rota de API que lê ou grava dados valida a sessão.
• Cada query que busca um registro por ID também filtra por dono ou tenant.
• Rotas de admin checam o papel no servidor, não uma flag no frontend.
• Teste: entre como usuário A, peça um recurso do usuário B e espere 403 ou 404.

Banco de dados

• Row Level Security ativo em todas as tabelas de schemas expostos, com políticas por usuário.
• No navegador, só a publishable ou anon key; secret e service_role, só no servidor.
• Queries parametrizadas, nunca montadas com concatenação de strings.

Dependências

• Cada pacote que a IA adicionou existe de verdade e é o que você procurava.
• Lockfile commitado, CVEs conhecidos verificados, pacotes sem uso removidos.

Configuração

• CORS restrito às suas próprias origens; cookies com Secure, HttpOnly e SameSite.
• Modo debug desligado e mensagens de erro genéricas em produção.
• Rate limiting em login, cadastro, reset de senha e tudo o que custa dinheiro (chamadas de IA, e-mails, SMS).
• GitHub Actions com permissões mínimas, containers que não rodam como root, nenhum bucket público por acidente.

Como revisar um app feito com vibe coding

Peça à IA uma passada de segurança, mas não pare aí. Um prompt como "revise isto procurando problemas de segurança" encontra algumas coisas, mas o mesmo modelo que escreveu o código tende a ter os mesmos pontos cegos. Na nossa análise da revisão de segurança com Claude Code você vê o que uma revisão feita por assistente pega e o que deixa passar.

Use scanners dedicados. Scanners de segredos, de dependências e análise estática pegam os problemas mecânicos com baixo custo. Nossa lista de scanners de vulnerabilidades open source é um bom ponto de partida gratuito, e o AI SAST acrescenta raciocínio sobre autorização e fluxo de dados, que é onde o IDOR se esconde.

Use uma revisão pensada para código gerado por IA. Por exemplo, com o Nurbak você conecta o GitHub e escaneia um repositório. O próprio modelo de IA self-hosted do Nurbak analisa o código (a análise não envia seu código para a OpenAI nem para a Anthropic) e aponta vulnerabilidades exploráveis com arquivo e linha, CVEs de dependências, configurações inseguras de GitHub Actions, Docker, Terraform e Kubernetes, e segredos no histórico do git, com uma nota de 0 a 100 e explicações em linguagem simples. Ele também pode abrir um Pull Request com a correção e um teste de regressão de segurança (a correção usa Claude, só com o seu consentimento explícito). O scan gratuito mostra por completo os 3 achados mais importantes. Veja como funciona o AI code review de segurança.

Traga pessoas quando o risco justificar. Falhas de lógica de negócio e ataques encadeados ainda precisam de alguém pensando. Se você vende para empresas, recebe pagamentos ou guarda dados sensíveis, planeje um pentest antes de um grande lançamento. Nosso guia para escolher uma empresa de pentest explica o que pedir, e uma auditoria de segurança do código é uma opção mais leve entre um pentest e outro.

Conclusão

Vibe coding não é ruim; vibe coding sem revisão é. A mesma velocidade que permite lançar num fim de semana deixa passar uma checagem de auth faltando, uma chave vazada ou um pacote inventado. Trate o código gerado por IA como o de um dev júnior rápido e talentoso: útil, muitas vezes certo, e nunca mergeado em produção sem revisão. Rode o checklist, automatize o escaneamento com um AI code review a cada mudança e deixe as pessoas para os momentos críticos.

Artigos relacionados

• Supabase RLS: o guia completo
• O que é uma vulnerabilidade IDOR
• Ferramentas de detecção de segredos
• OWASP Top 10 2025
• Checklist de segurança de APIs