Apps feitos com vibe coding são seguros? 8 falhas a checar

Apps feitos com vibe coding são seguros?

Não por padrão: todos os grandes estudos citados aqui encontraram falhas graves de segurança em grande parte dos apps que examinaram ^[3][4][5]. Os apps costumam funcionar. O problema é o que eles permitem que estranhos façam.

Uma auditoria de 2026 reuniu 9.041 apps de código aberto criados com Claude Code e Lovable e examinou 200 que estavam publicados. Encontrou 1.186 vulnerabilidades, e 182 dos 200 apps (91,0%) tinham pelo menos uma ^[4]. Dessas falhas, 65,77% foram classificadas como críticas ou altas, incluindo 18,47% críticas ^[4].

Os autores também testaram se prompts e configurações de agentes melhores resolvem o problema. Eles o reduziram, mas não o eliminaram, e a mesma tarefa executada três vezes podia gerar um resultado seguro numa vez e inseguro na seguinte ^[4]. Ou seja, um resultado limpo em uma versão diz pouco sobre a próxima.

Para o básico do método, veja o guia da Pouyam Vibe Coding Explained: What It Is, How It Works and the Real Risks. Para um primeiro projeto, Vibe Coding for Beginners: How to Start Safely in 2026 traz um plano inicial. Esta página desce um nível: as falhas específicas e como testar cada uma.

O que os estudos de segurança encontram em apps de vibe coding?

Quatro fontes independentes apontam o mesmo ponto fraco: dados que a pessoa errada pode ler ou alterar ^[1][3][4][5].

• Auditoria de 200 apps publicados (2026): o controle de acesso falho foi a maior categoria, com 339 de 1.186 falhas (28,58%), e afetou 64,00% dos apps. A injeção afetou 54,00% e as falhas de autenticação, 51,50% ^[4].
• Estudo da ACM CCS 2026: em 8.641 repositórios do Lovable com histórico completo, 11,2% das regras de leitura estavam abertas a visitantes sem login e 61,2% dos repositórios tinham ao menos uma regra assim. Um teste de repetição confirmou a exposição em 353 de 400 repositórios da amostra ^[5].
• Escape (outubro de 2025): uma varredura passiva de mais de 5.600 apps públicos criados em plataformas como Lovable, Base44 e Create.xyz encontrou mais de 2.000 vulnerabilidades, mais de 400 segredos expostos e 175 casos de dados pessoais, incluindo prontuários médicos, IBANs (identificadores de contas bancárias), telefones e e-mails ^[3].
• CVE-2025-48757 (2025): uma varredura concluída em 21 de março de 2025 encontrou 303 endpoints de banco de dados em 170 de 1.645 projetos do Lovable, cerca de 10,3%, com regras de linha inadequadas ^[1].

A Escape ressalta que sua varredura evitou qualquer ação destrutiva, então os números são um piso; um teste mais profundo encontraria mais ^[3]. A mesma cautela vale para todos os números aqui: esses estudos contam o que conseguiam ver de fora.

Por que ferramentas de IA criam apps inseguros?

Porque as ferramentas buscam um app que funcione, e as regras de segurança dependem de detalhes do negócio que o prompt raramente explica ^[4][11].

Código que roda é fácil de checar: a página carrega, o botão responde. Quem pode ver cada registro é uma decisão de negócio, e se ninguém a escreve, a ferramenta precisa adivinhar. A auditoria de 2026 liga as falhas a oito padrões recorrentes, agrupados em três limites dos agentes de IA: memória, objetivos e conhecimento ^[4].

Testes amplos de modelos de IA mostram a mesma lacuna. O GenAI Code Security Report 2026 da Veracode concluiu que, em seus testes, cerca de 44% das tarefas de geração de código introduziram uma vulnerabilidade de segurança ^[11]. Um benchmark citado pela AWS mostrou que a melhor de 12 configurações de agentes resolveu corretamente 57% das tarefas, mas só 11,8% de forma correta e segura ao mesmo tempo ^[10].

Muitos apps de vibe coding também transferem a segurança para o banco de dados. O navegador fala direto com um banco hospedado, então as regras dele são a única barreira entre um visitante e cada linha ^[1][6]. Se as regras faltam ou são amplas demais, qualquer pessoa que saiba o endereço pode pedir tudo.

Quais 8 falhas de segurança devo checar primeiro?

Comece pelas falhas que os estudos mais encontram, em ordem de dano possível ^[1][3][4][5].

1. Regras de banco de dados abertas: tabelas sem row level security ou com regras que deixam qualquer visitante ler todas as linhas. Foi a raiz do CVE-2025-48757 e dos achados da ACM ^[1][5].
2. Controle de acesso falho: um usuário logado abre o registro de outro trocando um ID no endereço ou na requisição. Foi a maior categoria da auditoria de 2026 ^[4].
3. Chaves secretas no navegador: uma chave secret ou service_role do Supabase, uma chave de pagamento ou de um provedor de IA colocada no código do front-end. A Escape encontrou mais de 400 segredos expostos ^[3][6].
4. Checagem de login ausente ou fraca: páginas privadas ou rotas de API que respondem sem sessão. Falhas de autenticação atingiram 51,50% dos apps auditados ^[4].
5. Injeção: dados do usuário que chegam a consultas ou ao HTML sem validação, encontrada em 54,00% dos apps auditados ^[4].
6. Tabelas graváveis: regras que deixam visitantes inserir ou alterar dados, não só ler. No caso do CVE, uma requisição sem token de login inseriu um registro marcado como "pago" e pulou a etapa de pagamento ^[1].
7. Respostas que vazam dados: APIs que devolvem registros inteiros, e-mails ou tokens quando a página só precisa de um nome. A Escape contou 175 casos de dados pessoais expostos ^[3].
8. Acesso arriscado de agentes: um agente de código com credenciais de produção pode causar dano real; em julho de 2025, um agente apagou um banco de dados em produção durante um congelamento de código ^[10].

As falhas 1 a 4 cobrem a maior parte do que atacantes externos exploram, então teste-as primeiro.

Como testar meu app de vibe coding contra essas falhas?

Use o app como um atacante usaria: como estranho, como segundo usuário e lendo o que o navegador recebe ^[1][4][5]. Nenhum passo exige ferramentas especiais.

1. Crie duas contas de teste. Crie um registro com a conta A, copie o endereço ou ID, entre com a conta B e tente abrir, editar e apagar o registro. Se funcionar, o controle de acesso está falho ^[4].
2. Repita sem login. Abra os mesmos endereços numa janela anônima sem sessão. No caso do CVE, remover o cabeçalho de login bastou para driblar todas as checagens ^[1].
3. Observe a aba de rede. Nas ferramentas de desenvolvedor do navegador, veja cada requisição da página e o que volta. As respostas devem ter só o que aquela tela precisa, nunca e-mails ou tokens de outros usuários ^[3].
4. Procure chaves no código da página. Busque textos que comecem com sb_secret_, o rótulo service_role ou chaves de provedores, como de pagamento ou IA. Uma chave publishable é esperada; uma chave secret é uma emergência ^[6].
5. Confira as regras de cada tabela. No painel do banco de dados, confirme que row level security está ativada em cada tabela e leia cada regra em termos simples: quem pode ler, quem pode gravar ^[7].
6. Teste entradas estranhas. Cole textos muito longos, aspas e tags HTML em cada formulário e veja se o app quebra ou os mostra como código ^[4].

Teste apenas apps que são seus ou que você tem permissão para testar. Não sonde apps de outras pessoas sem permissão por escrito.

Como corrigir regras abertas do Supabase e chaves vazadas?

Ative row level security em todas as tabelas, escreva regras restritas, mantenha chaves secretas no servidor e troque qualquer chave vazada ^[6][7][8].

• Ative row level security em tudo. O guia do Supabase diz para ativá-la em todas as tabelas de um esquema exposto ^[7]. Depois disso, a chave pública não acessa nada até você adicionar regras ^[7].
• Remova permissões padrão. Em projetos que ainda as concedem por padrão, uma nova tabela pública começa com todos os privilégios já concedidos aos papéis sem login (anon) e com login (authenticated), e adicionar regras não os revoga ^[7]. Revogue-os e devolva apenas o que cada papel precisa ^[7].
• Escreva regras por usuário. A regra de uma tabela privada deve corresponder ao ID do usuário logado, e não apenas liberar qualquer pessoa logada. Evite regras sempre verdadeiras em tabelas sensíveis ^[2].
• Mantenha chaves secretas no servidor. A chave publishable do Supabase só é segura no navegador porque as regras de linha a limitam; as chaves secret e service_role ignoram todas as regras e devem ficar no código do servidor ou em variáveis de ambiente seguras ^[6].
• Troque chaves vazadas. Se uma chave secreta chegou ao navegador ou a um repositório de código público, troque-a e desative a comprometida, como recomenda o guia de chaves do Supabase ^[6].

Em 15 de novembro de 2026, a documentação do Supabase diz que vai descontinuar as antigas chaves anon e service_role até o fim de 2026 em favor das chaves publishable e secret ^[8]. As novas chaves secret retornam um erro (HTTP 401) quando usadas em um navegador, embora uma chave vazada ainda possa ser usada a partir de outras ferramentas ^[6][8]. Migrar agora é uma boa hora para revisar cada chave que um app usa.

Os scanners de segurança integrados pegam tudo?

Não: os scanners das plataformas ajudam, mas vários estudos mostram que eles deixam passar as regras mais importantes ^[1][2][5].

Em 2025, os pesquisadores por trás do CVE-2025-48757 viram que o scanner do Lovable só verificava se havia uma regra de linha, não se ela estava correta ^[1]. O alerta deles acrescenta que a checagem de publicação do Lovable aponta tabelas sem regras, mas não mostra se as regras são restritas o bastante ^[2]. Uma regra aberta passa por uma checagem assim.

O estudo da ACM confirma com números: uma parcela modesta de regras abertas, 6,3% em seis ferramentas, ainda deixou 56,9% dos repositórios com ao menos uma tabela exposta, porque uma regra aberta basta ^[5]. Os autores lançaram um verificador gratuito que aponta essas regras antes do commit ^[5].

Use scanners como primeiro filtro e faça você mesmo os testes com duas contas e sem login. A tabela abaixo resume os números.

É seguro usar apps que outras pessoas fizeram com vibe coding?

Tenha cuidado com qualquer app que peça dados pessoais, de saúde ou de pagamento, porque os usuários não conseguem ver como ele os protege ^[3][4]. A Escape encontrou prontuários médicos e IBANs (identificadores de contas bancárias) entre os dados expostos ^[3].

Alguns hábitos simples reduzem o risco. Use uma senha diferente para cada app novo, para que um vazamento não abra outros; o guia da Pouyam Password Managers Explained: How They Work and Whether They Are Safe explica como. Compartilhe só os dados de que o app precisa e prefira páginas de pagamento de provedores conhecidos a formulários dentro do app.

A principal responsabilidade é de quem cria. Se você publica um app que guarda dados de outras pessoas, faça as checagens acima antes do lançamento e depois de cada grande mudança, porque um único recurso novo pode reabrir uma falha já fechada ^[4][5].