Vibe coding com segurança: o guia para quem cria app conversando com a IA

Criar app conversando com a IA é rápido — e é fácil publicar algo aberto. O que pedir, o que conferir e o que fazer se o app já está no ar.

Vibe coding é criar software descrevendo o que você quer para uma IA — no Lovable, no Bolt, no v0, no Cursor, no Claude Code — e ir ajustando pelo resultado, sem escrever cada linha. Funciona: dá para ter um app com login, banco e pagamento em uma tarde.

O risco não é a IA "programar mal". É que ela mira em fazer funcionar. Quando algo dá erro de permissão, o jeito mais rápido de fazer funcionar é liberar a permissão — e o app volta a rodar, aberto para qualquer pessoa. Você só vê que funcionou; não vê o que ficou aberto.

As 4 regras que evitam quase todo problema

1. 1Segredo não vai para o navegador. Chave da OpenAI, do Stripe, a service_role do Supabase: tudo isso só existe no servidor (Edge Function, rota de API). No front, só chaves feitas para serem públicas.
2. 2O banco começa fechado. No Supabase, toda tabela com RLS ligada e política por usuário. No Firebase, nada de if true nem modo de teste esquecido.
3. 3Toda rota confere QUEM chama — e se aquele dado é DELE. Login não basta: o pedido 124 tem que ser do usuário logado, não de qualquer um que troque o número na URL.
4. 4Nada de montar SQL, comando ou URL colando o que o visitante digitou. Parâmetros, sempre.

Peça segurança no prompt — do jeito certo

"Deixe o app seguro" é vago demais: a IA responde que está seguro e segue. Funciona melhor pedir uma coisa verificável, dizer o que não pode mudar e pedir a prova:

Revise as tabelas do Supabase deste projeto.
1. Ligue a RLS em TODAS as tabelas do schema public.
2. Para tabelas com dados de usuário, crie políticas que usem auth.uid() = user_id
   (select, insert, update e delete separados). Não use using (true).
3. Não mude o formato das tabelas nem as telas.
4. No fim, me mostre o SQL aplicado e a lista de tabelas com rowsecurity = true.

Antes de publicar: 15 minutos de conferência

• Abra o site publicado, aperte F12 → Sources e busque por sk-, service_role, secret. Achou? É chave exposta.
• No Supabase, rode o Security Advisor. No Firebase, abra as regras e procure if true.
• Crie duas contas de teste. Logado na segunda, troque o id na URL de uma página da primeira. Se abriu, é IDOR.
• Confira se o .env está no .gitignore e se nunca foi para o GitHub.
• Ou rode npx vibedefender na pasta do projeto: faz as oito conferências de uma vez, na sua máquina.

O app já está no ar e achei um problema. E agora?

1. 1Corrija o que deixa alguém ler ou mudar dados de outras pessoas primeiro (tabela aberta, IDOR).
2. 2Troque TODA chave que ficou exposta, mesmo que por pouco tempo. Tirar do código não desfaz o vazamento: quem copiou continua com ela.
3. 3Olhe o uso das contas pagas (OpenAI, Stripe, Resend) em busca de consumo que não é seu.
4. 4Rode a conferência de novo depois de cada correção.

Dicas curtas de segurança para quem cria com IA: siga @npx_vibedefender no Instagram.