Como colocar um app de vibe coding no ar sem vazar dado de cliente

O projeto funciona. Você testou, o login entra, cada usuário vê os próprios dados na tela. Parece pronto para receber gente de verdade.

O problema é que o atacante não abre a sua tela. Ele fala direto com o seu banco, pelo mesmo endereço que o seu front usa, com a mesma chave que está no código que qualquer pessoa baixa ao abrir o site.

Este artigo é o que revisar antes desse dia.

Qual é o tamanho real do problema?

Três levantamentos públicos, com métodos diferentes, chegam ao mesmo lugar.

Um estudo sistemático publicado em junho de 2026, Understanding the (In)Security of Vibe-Coded Applications, coletou 9.041 aplicações open-source feitas com Claude Code e Lovable e auditou 200 delas já publicadas. Encontrou 1.186 vulnerabilidades. O número que importa: 91,0% das aplicações auditadas tinham pelo menos uma, e 65,77% das falhas foram classificadas como crítica ou alta. Elas se concentram em três famílias, e a primeira é a que este artigo trata: controle de acesso quebrado, injeção e falha de autenticação.

A Escape.tech escaneou mais de 5.600 aplicações públicas feitas com ferramentas de vibe coding e confirmou mais de 2.000 vulnerabilidades, 400 segredos expostos e 175 casos de dado pessoal à vista, incluindo prontuário, IBAN e telefone. A equipe descreve o recorte como conservador: só entrou na conta o que foi confirmado com alta confiança, então o número real é maior.

E o padrão já virou registro formal. O CVE-2025-48757, publicado em maio de 2025, descreve política de Row Level Security insuficiente no Lovable até 15/04/2025. A descrição oficial não deixa margem: permite que atacante remoto não autenticado leia ou escreva em tabelas arbitrárias dos sites gerados. Nota 9,3 de 10 na escala CVSS, classificado como CWE-863, autorização incorreta.

Nenhum desses três é sobre uma ferramenta ruim. É sobre o que o gerador entrega por padrão quando ninguém pede o contrário.

Por onde o dado escapa

Onde	O que acontece	Quanto tempo leva para explorar
Tabela sem Row Level Security	Qualquer pessoa com a chave pública lê a tabela inteira pela API	Segundos
Política de RLS permissiva	RLS está ligada, mas a regra é true. Usuário logado lê a linha de qualquer outro	Segundos
Chave de serviço no front	A chave service_role ignora RLS por definição. No navegador, ela é pública	Segundos
Permissão checada só na tela	O botão some, a rota da API continua respondendo	Minutos
Bucket de arquivo público	Documento e foto enviados por um cliente ficam legíveis por URL	Minutos
.env versionado	Chave de API, token de pagamento e senha de banco no histórico do Git	Minutos
Sem limite de requisição	Enumeração de registro e força bruta no login rodam sem freio	Horas

As três primeiras linhas explicam a maior parte dos casos, e todas são a mesma falha vista de ângulos diferentes: o banco confia em quem pergunta.

Como saber se você já está exposto

Faça isto no seu próprio projeto, agora. Leva menos de dez minutos e não depende de ferramenta paga.

1. Abra o site publicado e o DevTools do navegador. Na aba de rede, recarregue a página e procure a chamada ao seu banco. O endereço do projeto e a chave anon vão estar ali, em texto puro. Isso é esperado: essa chave é pública por desenho. O que não pode é ela ser suficiente.

2. Saia da conta. Apague o cookie e o localStorage. Você agora é um visitante qualquer.

3. Chame a API direto, sem passar pela sua interface. Troque SEU-PROJETO, SUA_CHAVE_ANON e o nome da tabela:

   curl "https://SEU-PROJETO.supabase.co/rest/v1/usuarios?select=*" \
     -H "apikey: SUA_CHAVE_ANON"

4. Leia a resposta. Se voltar [] ou um erro de permissão, essa tabela está protegida. Se voltar linha com dado dentro, a sua base está aberta para a internet. Repita para cada tabela que guarda algo sensível: usuário, pedido, pagamento, mensagem, arquivo.

5. Teste a escrita também. Leitura aberta é ruim. Escrita aberta é pior, porque permite adulterar registro sem deixar rastro óbvio.

6. Procure segredo no que você publicou. No bundle do front, busque por service_role, sk_live, SECRET e PRIVATE. Qualquer achado precisa ser rotacionado, não só removido: o que foi publicado já foi visto.

7. Verifique o histórico do Git. Tirar o .env do último commit não apaga o anterior. Use git log -p --all -- .env e rotacione tudo que aparecer.

Se o passo 4 devolveu dado, pare de ler e vá para a última seção.

O checklist antes de publicar

Banco

• Row Level Security ligada em toda tabela, sem exceção. Tabela nova nasce desligada, então isso é revisão de cada migração, não tarefa de uma vez só.
• Política que nomeia o dono da linha. Uma regra que devolve true para todo mundo tem RLS ligada e protege nada.
• A chave service_role nunca sai do servidor. Ela existe justamente para ignorar RLS.
• Coluna sensível fora do select *. Hash de senha, documento e token não precisam trafegar para a tela.

Autenticação e permissão

• Toda checagem de permissão roda no servidor. Esconder o botão de administrador não fecha a rota do administrador.
• Confirmação de e-mail ligada, senão qualquer endereço inventado vira conta.
• Limite de tentativa no login e nas rotas de escrita.

Segredos

• .env no .gitignore antes do primeiro commit, e chave de produção só na variável de ambiente da hospedagem.
• Chave de terceiro com escopo mínimo. Chave de pagamento que só cobra não deve poder estornar.
• Rotação de tudo que já apareceu em código publicado.

Arquivo e dado pessoal

• Bucket privado por padrão, com acesso por URL assinada de validade curta.
• Nome de arquivo não sequencial. contrato-1.pdf convida a tentar o contrato-2.pdf.
• Só colete o que você usa. Dado que não existe na base não vaza.

Depois de publicar

• Log de acesso guardado e um lugar onde alguém olha para ele.
• Backup testado. Backup que nunca foi restaurado é uma suposição.

E se o dado já vazou?

No Brasil isso tem prazo em regulamento, e ele é curto.

A Resolução CD/ANPD nº 15/2024 regulamenta o artigo 48 da LGPD. O artigo 6º estabelece que a comunicação do incidente à ANPD deve ser feita pelo controlador no prazo de três dias úteis, contado de quando ele toma conhecimento de que o incidente afetou dado pessoal. Para agente de tratamento de pequeno porte, o prazo conta em dobro.

A comunicação exige conteúdo específico, entre outros itens: natureza e categoria do dado afetado, número de titulares atingidos, medidas de segurança em uso antes e depois, riscos e impactos, a causa raiz, as datas de ocorrência e de descoberta, e as medidas de correção.

Duas consequências práticas disso, e nenhuma é intuitiva:

O relógio começa na descoberta, não no vazamento. Adiar a investigação não adia o prazo, porque a data de ocorrência também entra no formulário.

O regulamento pede a causa raiz. Quem descobre o vazamento e conserta sem registrar o que aconteceu perde a informação que a comunicação exige.

Se você chegou aqui com dado exposto, a ordem é: feche o acesso, rotacione as chaves, levante o que foi acessado nos logs, e só então comunique. As quatro coisas cabem em três dias úteis. Nenhuma delas cabe em três dias úteis se você começar no terceiro.

O que este checklist não resolve

Ele fecha a porta mais usada, e não audita o seu código.

Duas das três famílias de falha do estudo citado acima continuam de fora: injeção e falha de autenticação pedem revisão de código, não configuração. E o próprio estudo registra que melhorar o prompt e o ambiente do agente reduz a incidência de vulnerabilidade sem eliminar o risco de fundo.

Serve de piso. Um projeto que passa nos sete testes da seção anterior não está seguro; está fora da faixa que qualquer pessoa explora com um curl.

Nota de transparência. Os números deste artigo vêm dos três levantamentos citados, todos públicos e linkados. A Rampex não publicou estatística própria sobre projetos auditados, e este texto não apresenta nenhuma como se fosse. Quando essa base estiver consolidada, ela entra aqui e a data de atualização muda.