Segurança no vibe coding: os riscos que as ferramentas de IA deixam

A segurança no vibe coding gira, na maior parte, em torno de um pequeno conjunto de falhas recorrentes que as ferramentas de IA deixam para trás: regras fracas sobre quem pode ler quais dados, chaves secretas que acabam no navegador e lógica de pagamento que confia no sinal errado. O app normalmente funciona em uma demo, e é justamente por isso que essas falhas passam despercebidas.

Sou engenheiro sênior e trato código gerado por IA como um primeiro rascunho. Um rascunho pode ser bom, mas alguém que entende os riscos precisa lê-lo antes da chegada de usuários e pagamentos reais. Este artigo mostra o que eu verifico primeiro e o que você mesmo pode verificar.

Quais são os riscos de segurança mais comuns em apps feitos com vibe coding?

Nos apps construídos com IA que eu analiso, os mesmos tipos de problema tendem a se repetir. Eles não são exóticos; são o básico que uma demo nunca coloca à prova.

• Regras fracas de acesso a dados. Qualquer usuário logado, ou até um visitante anônimo, consegue ler ou editar linhas que pertencem a outras pessoas.
• Segredos no navegador. Chaves de API ou credenciais de serviços embutidas no código do frontend.
• Pagamentos confirmados pelo cliente. O app marca um pedido como pago porque o navegador disse isso, não porque o provedor de pagamentos confirmou.
• Falta de backups. Ninguém testou restaurar o banco de dados.
• Nenhum limite. Sem rate limiting, sem validação de entradas no servidor, sem verificações nos uploads de arquivos.

Quatro verificações cobrem a maior parte do risco antes dos usuários reais: regras de acesso a dados, chaves expostas, confirmação de pagamento e backups. Você não precisa de uma auditoria completa para encontrar os piores problemas. Algumas verificações focadas resolvem, e corrigir as coisas sai mais barato antes da chegada de usuários e pagamentos reais.

Por que as ferramentas de IA erram nas regras de dados?

Um construtor de apps com IA otimiza para uma funcionalidade que funciona quando você clica nela. Se você pede uma página que lista as faturas de um usuário, ele faz a página funcionar. Se o banco de dados se recusa a devolver as faturas de outra pessoa é outra questão, e ninguém perguntou.

No Supabase, essa recusa é a row level security. Se a RLS está desativada, ou se uma política diz algo como “permitir que todos os usuários autenticados leiam”, o frontend pode continuar parecendo correto enquanto os dados estão abertos. Apps construídos com Lovable têm mostrado um padrão de regras de RLS fracas, então essa é a primeira coisa que eu verifico.

Uma verificação rápida que você mesmo pode fazer

1. Crie duas contas de teste.
2. Com a conta A, crie alguns dados.
3. Com a conta B, tente buscar as linhas da conta A usando as ferramentas de desenvolvedor do navegador ou a API diretamente, não a interface do app.
4. Repita sem estar logado.

Se a conta B ou um visitante anônimo enxergar qualquer coisa, suas regras estão erradas. Procure também tabelas com RLS desativada e políticas que sempre resultam em verdadeiro. Esconder um botão na interface não é uma regra; quem precisa garantir isso é o banco de dados.

Como as chaves secretas acabam no navegador?

Apps gerados costumam chamar serviços de terceiros direto do frontend, porque esse é o caminho mais curto para uma funcionalidade funcionar. O modelo precisa de uma chave para fazer a chamada, então a chave vai para o código do cliente ou para uma variável de ambiente que a ferramenta de build embute na página.

Tudo o que chega ao navegador é público. Qualquer pessoa pode abrir as ferramentas de desenvolvedor, buscar no JavaScript carregado e copiar a chave. Algumas chaves foram feitas para serem públicas, como a anon key do Supabase, e só são seguras se as suas regras de dados forem fortes. Outras não: chaves secretas de pagamento, chaves service-role, chaves de provedores de e-mail e chaves de provedores de IA que cobram por requisição.

O que verificar

• Procure no seu repositório e no JavaScript publicado por strings que pareçam chaves.
• Verifique qualquer variável com prefixo público; essas são enviadas ao cliente por design.
• Olhe o histórico do Git, porque uma chave removida hoje ainda pode estar em um commit antigo.
• Troque qualquer segredo que já tenha sido exposto. Apagá-lo do código não basta.

A correção é mover as chamadas que precisam de segredos para uma função de servidor ou um backend, e deixar que o navegador chame essa função.

Que incidentes públicos afetaram construtores de apps com IA?

Em julho de 2025, pesquisadores da Wiz descobriram que o Base44, construtor de apps com IA da Wix, permitia que um atacante se cadastrasse em apps que deveriam ser privados usando apenas o ID do app. A falha foi corrigida em um dia. A lição não é que uma ferramenta seja especialmente ruim; é que a própria camada de autenticação do construtor faz parte da segurança do seu app, e que apps privados dependem dela.

O padrão do Lovable com o Supabase é diferente. É menos um incidente isolado e mais uma fragilidade de configuração recorrente em apps gerados, em que as regras de RLS estão ausentes ou são permissivas demais. Estou me limitando ao que foi documentado publicamente e não tiraria conclusões mais amplas disso.

Os dois casos mostram a mesma coisa: um app construído por prompts pode parecer pronto enquanto a camada de acesso por baixo está aberta.

Pelo que o construtor é responsável, e pelo que você é responsável?

Segurança é uma responsabilidade compartilhada. O construtor protege a infraestrutura e as contas dele. Você, como dono do app, é responsável por quem pode ler quais dados e pelos dados dos seus usuários.

Às vezes, continuar no construtor é a melhor escolha, principalmente para uma ferramenta interna ou uma validação inicial com poucos dados sensíveis. Se você realmente superar o construtor, o código feito no Lovable pode ser levado para o GitHub e para a sua própria hospedagem. Mudar, porém, não corrige nada por si só; as mesmas regras e chaves vão junto.

Posso pedir para a IA corrigir os próprios bugs de segurança?

Em parte. Ela é útil para problemas claros e localizados: adicionar validação de entradas, restringir uma política que você descreve com precisão ou mover uma chamada para uma função de servidor. Mas regras de dados, chaves e fluxos de pagamento são exatamente o que as ferramentas costumam errar, e o mesmo ponto cego que criou o bug muitas vezes o esconde na revisão.

Dois problemas se destacam. Primeiro, a IA muitas vezes diz que a correção está feita sem provar. Segundo, ela não tem como conhecer as suas regras de negócio, como quem deve ver uma fatura ou o que acontece quando um webhook de pagamento chega duas vezes ou fora de ordem. Scanners de segurança genéricos também deixam isso passar, porque pedidos duplicados e webhooks do Stripe não verificados são lógica de negócio, não padrões de vulnerabilidade conhecidos.

Minha abordagem: testar com a verificação de duas contas descrita acima, pedir para uma pessoa ler as políticas e o código de pagamento e corrigir os problemas de maior risco no código existente antes mesmo de cogitar uma reescrita. Use a IA como assistente para as edições, não como juíza de se elas funcionaram.

Quer uma segunda opinião sobre o seu app?

Se você construiu algo com uma ferramenta de IA e quer trocar ideias, mande um e-mail para me@filipeeduardo.dev com o link e eu digo o que verificaria primeiro. Esta é uma orientação geral, não uma garantia de segurança.