Um app vibe-codado pode rodar perfeitamente na sua frente e ainda assim estar completamente aberto por baixo. Essa é a parte desconfortável da geração de apps por IA: a demo funciona, o cliente fica impressionado, e nada disso diz se a tela de login pode ser contornada ou se o banco de dados está exposto a qualquer um que inspecione uma requisição de rede.
Os modelos de IA são treinados para produzir algo que pareça pronto. Não são treinados para perguntar «quem mais poderia alcançar esse endpoint». É nessa lacuna que mora a maior parte do risco real em software gerado por IA, e ele raramente aparece antes que alguém vá procurá-lo.
Os números são piores do que a maioria dos criadores imagina
Pesquisas independentes sobre código gerado por LLM confirmam isso com uma estatística específica e desconfortável: os modelos compilam código funcional com sucesso em cerca de 90% dos casos, mas aproximadamente 45% desse código carrega pelo menos uma vulnerabilidade do OWASP Top 10, coisas como verificações de login contornáveis ou falhas de injeção que permitem a um atacante manipular uma consulta.
Isso não é um caso raro. Significa que quase metade do que uma ferramenta como Lovable, Bolt ou Base44 gera para você a partir de um prompt tem, desde o início, uma fragilidade real e explorável. O app continua «funcionando» em todos os aspectos visíveis. A vulnerabilidade simplesmente não se manifesta até que um usuário (ou atacante) a encontre.
De onde o risco realmente vem
As falhas de segurança em apps gerados por IA tendem a se concentrar em alguns padrões que se repetem:
- Verificações de autenticação no lado do cliente. A IA implementa «este usuário tem permissão para ver esta página» no navegador em vez de no servidor. Como o código do navegador é totalmente visível e editável, qualquer pessoa pode abrir as ferramentas de desenvolvedor, inverter a verificação e entrar.
- Segredos codificados diretamente no código. Criadores não técnicos que testam localmente muitas vezes não sabem gerenciar corretamente os arquivos
.env, então as chaves de API e as strings de conexão do banco de dados acabam digitadas diretamente no código. Esses arquivos depois vão parar em um repositório público do GitHub sem que ninguém perceba. - Regras de banco de dados permissivas demais. Para fazer um prompt funcionar rápido, a IA configura o acesso ao banco de dados de forma ampla, em vez de restrita. Se qualquer outra parte do app for comprometida, essa configuração totalmente aberta transforma um pequeno bug em um vazamento de dados completo.
- Conexões OAuth com escopo excessivo. Configurar uma integração como Google Calendar ou Slack exige definir os escopos do OAuth manualmente. Pedir acesso demais cria uma responsabilidade; esquecer um escopo quebra a integração silenciosamente. De qualquer forma, o criador está tomando uma decisão de segurança que, na maioria das vezes, nem percebe que está tomando.
Nada disso aparece em uma demo. Aparece em uma auditoria de segurança, no console do navegador de um usuário curioso, ou em uma notificação de vazamento meses depois.
Por que «funciona» é o teste errado
A armadilha é que os geradores de apps com IA recompensam a velocidade de lançamento, e ciclos de feedback rápidos treinam você a testar apenas o caminho ideal. Você percorre o fluxo de cadastro, o painel carrega, o formulário é enviado, tudo parece certo. Nada disso diz se a ação CRUD por trás desse formulário verifica quem está fazendo a solicitação.
Testar a segurança de verdade significa fazer outras perguntas:
- Um usuário deslogado consegue acessar essa URL diretamente?
- O usuário A consegue ver ou editar os registros do usuário B mudando um ID na barra de endereço?
- As verificações de função são aplicadas no servidor, ou só estão escondidas na interface?
- As integrações conectadas via OAuth solicitam apenas os escopos que realmente usam?
A maioria dos criadores não técnicos não sabe que precisa fazer essas perguntas, e a maioria dos assistentes de código com IA não as levanta espontaneamente, a menos que você diga explicitamente «revise isso em busca de problemas de segurança»; e mesmo assim, a correção é apenas mais um patch gerado, não uma garantia estrutural.
A alternativa: infraestrutura que você não precisa auditar
Esse é o verdadeiro argumento para construir apps de negócio sobre uma plataforma com segurança embutida na fundação, em vez de gerada a cada projeto. Softr é um bom exemplo da abordagem oposta: autenticação, permissões por função e regras de acesso a dados são recursos nativos da plataforma, não código que a IA reescreve a cada app.
Na prática, isso significa:
- CRUD no servidor por padrão. As ações de leitura/escrita no banco de dados rodam nos servidores da Softr, não no navegador, então não existe verificação no lado do cliente para contornar em primeiro lugar.
- Permissões de função visuais em vez de RLS escrito à mão. Grupos de usuários e restrições de dados controlam quem vê e edita quais registros, configurados visualmente e verificados por personificação na pré-visualização, em vez de enterrados em código de política de banco de dados fácil de configurar errado.
- Conectores OAuth pré-verificados. Integrações com ferramentas como Google Calendar, HubSpot e Stripe usam as aplicações de desenvolvedor já aprovadas da Softr, então os criadores nunca lidam com escopos OAuth brutos nem armazenam credenciais de terceiros por conta própria.
- Fluxos de autenticação utilitários prontos de fábrica. Login, redefinição de senha, OTP e cadastro restrito por domínio já vêm prontos, então não há lógica de autenticação personalizada que uma IA possa errar de forma sutil.
Isso não significa que ferramentas geradas por IA sejam inadequadas para tudo. Para um projeto pessoal, um protótipo interno que ninguém fora da sua equipe vai tocar, ou uma landing page estática, o perfil de risco é baixo e o vibe coding é de fato o caminho mais rápido. O cálculo muda no momento em que entram usuários reais, dados reais de clientes ou logins externos.
O que verificar antes de lançar
Se, ainda assim, você for construir com uma ferramenta de IA que gera código, uma lista curta é melhor do que nenhuma:
- Faça uma busca (grep) no código por chaves de API e strings de conexão codificadas diretamente antes de qualquer commit.
- Confirme que as verificações de controle de acesso também estão duplicadas no servidor, e não apenas escondidas no frontend.
- Revise os escopos OAuth concedidos a cada integração conectada e remova o que não é usado.
- Peça a uma segunda pessoa, de preferência alguém técnico, que tente acessar os dados de outro usuário adivinhando ou alterando um ID na URL.
Essa lista não vai deixar o código gerado tão seguro quanto uma infraestrutura que nunca foi gerada, mas ela pega as falhas que aparecem com mais frequência. Para um portal, um CRM ou uma ferramenta interna em que pessoas reais vão entrar com dados reais, a solução mais duradoura é escolher uma base onde o trabalho de segurança já foi feito, para que não seja uma loteria a cada prompt.