---
title: "Vibe coding e segurança: o app funciona, mas está aberto pra quem?"
description: "Lovable, v0, Replit, Claude Code e Codex colocam um app no ar numa tarde. O que quase ninguém confere é quem mais consegue ler os dados dele. Os casos reais, um checklist antes de publicar e o curso que eu indico pra fazer isso direito."
published: "2026-10-24"
tags: ["ia", "seguranca", "vibe-coding", "curso"]
source: "https://marciotoledo.com/blog/vibe-coding-seguranca-dados-expostos"
---

# Vibe coding e segurança: o app funciona, mas está aberto pra quem?

Toda semana aparece no meu feed alguém comemorando: "fiz um CRM inteiro numa tarde, sem saber programar". E é verdade. A tela abre, o login funciona, o cliente aparece na lista, o gráfico sobe. Dá vontade de aplaudir, e eu aplaudo, porque eu também uso IA pra programar todo dia.

O que me tira o sono é a pergunta que ninguém faz no vídeo de 40 segundos: **quem mais consegue ver esses dados?**

Porque "funcionar" e "estar protegido" são coisas diferentes. Um app pode funcionar perfeitamente pra você e, ao mesmo tempo, deixar a tabela de clientes, os telefones, os pagamentos e as chaves de API abertos pra qualquer pessoa que souber abrir o DevTools do navegador. Ou pior: pra qualquer um que souber pesquisar no Google.

## O que é vibe coding, rapidamente

O termo foi cunhado pelo Andrej Karpathy em fevereiro de 2025: você descreve o que quer em linguagem natural, a IA escreve o código, você aceita as mudanças sem ler muito e vai ajustando pelo resultado na tela. Você "vai na vibe".

As ferramentas mais usadas pra isso se dividem em dois grupos:

- **Plataformas que já publicam o app**: Lovable, v0 (da Vercel), Replit, Bolt e Base44. Você conversa, ela gera, sobe banco de dados e coloca no ar com uma URL pública.
- **Agentes que trabalham no seu computador**: Claude Code, Codex, Cursor. Mais poder, mais controle, e também mais formas de dar errado, porque o agente tem acesso ao seu terminal, aos seus arquivos e, se você deixar, ao seu servidor.

Nenhuma delas é o problema. O problema é a gente achar que, porque a tela funciona, o trabalho acabou.

## Onde o vibe coding estraga a festa

A IA otimiza pra uma coisa: fazer o que você pediu aparecer funcionando. Se você pediu "uma lista de clientes com filtro", ela entrega uma lista de clientes com filtro. Ela não vai, por conta própria, perguntar "e quem **não** deveria ver essa lista?". Essa pergunta é sua.

Na prática, os vazamentos de app feito com IA quase sempre caem em quatro buracos:

1. **Banco de dados sem regra de acesso.** Boa parte dessas plataformas usa o Supabase como backend. O app no navegador fala direto com o banco usando uma chave pública (a `anon key`). Isso é normal e seguro **desde que** cada tabela tenha Row Level Security (RLS) configurada, dizendo quem pode ler e escrever o quê. Sem RLS, ou com uma política mal escrita, aquela chave pública vira chave mestra: qualquer pessoa copia a chave do código da página e lê a tabela inteira.
2. **Segredo no lugar errado.** Chave da OpenAI, do Stripe, do Google Maps, token de serviço do Supabase. Se está no código que roda no navegador, está público. Não existe "escondido no JavaScript".
3. **Tela protegida, API aberta.** A IA cria a tela de login e esconde o painel de quem não está logado. Mas o endpoint que alimenta o painel responde pra qualquer um que chamar direto. O "cadeado" é só visual.
4. **Coisa que deveria ser privada publicada como pública.** Painel interno, CRM, dashboard de vendas, ferramenta de RH. Foi feito pra três pessoas da empresa, mas ganhou uma URL pública, sem senha, e o Google indexou.

Esse último é o mais fácil de ver com os próprios olhos.

> **WARNING**
>
> **Faça o teste agora.** Pesquise no Google:
>
> - `site:lovable.app crm`
> - `site:lovable.app dashboard`
> - `site:lovable.app painel`
>
> Em poucos segundos aparecem dezenas de CRMs, painéis administrativos e dashboards publicados e indexados. Muitos são demonstração, com dado fictício. Mas uma parte não é: tem nome de cliente, telefone, valor de contrato. E se o Google achou, qualquer pessoa acha.
>
> Um aviso importante: **olhe, entenda o tamanho do problema e pare por aí.** Explorar ou alterar dado de terceiro sem autorização pode ser crime no Brasil (Lei 12.737/2012), e quem deixou vazar responde pela LGPD. Se encontrar um app seu nessa lista, corrija hoje. Se encontrar o de alguém que você conhece, avise.

E não é só o Lovable. Troque o domínio pelo das outras plataformas e o padrão se repete. O Lovable só aparece mais porque é o maior e porque a URL pública vem de fábrica.

## Os casos que já aconteceram

Isso não é teoria de quem quer vender medo. Separei os casos mais documentados:

| Caso | O que aconteceu | Causa |
| :--- | :--- | :--- |
| **Lovable, CVE-2025-48757** (2025) | Pesquisadores analisaram 1.645 apps da vitrine do Lovable e encontraram 170 (cerca de 10%) com dados abertos: nomes, e-mails, telefones, pagamentos e chaves de API. Num deles dava pra marcar um pagamento como pago sem passar pelo Stripe | RLS ausente ou mal configurada no Supabase |
| **Escape.tech** (out/2025) | Varredura passiva em mais de 5.600 apps públicos feitos com Lovable, Base44, Create.xyz, Bolt e outros: mais de 2.000 vulnerabilidades, mais de 400 segredos expostos e 175 casos de dado pessoal, incluindo registro médico e dado bancário | Falta de autenticação, chaves no frontend, RLS errada |
| **Base44** (jul/2025) | A Wiz achou uma falha que permitia criar conta verificada em apps **privados** de empresas sabendo só o `app_id`, que aparecia na própria URL. Corrigido em menos de 24 horas | Endpoint de cadastro sem autenticação na plataforma |
| **Moltbook** (2026) | A rede social de agentes de IA deixou o banco inteiro aberto: 1,5 milhão de tokens de API, 35 mil e-mails e mensagens privadas, com leitura e escrita | Chave do Supabase no JavaScript, sem RLS |
| **Replit e o SaaStr** (jul/2025) | Num experimento de vibe coding, o agente do Replit apagou o banco de produção do Jason Lemkin, fundador do SaaStr, mesmo com a instrução de não mexer sem autorização. Depois disse que não dava pra restaurar, e dava | Agente com acesso direto à produção, sem separação de ambientes |

O caso do Lovable tem um detalhe que diz muito: a empresa contestou o CVE argumentando que **cada cliente é responsável por proteger os dados do próprio app**. Juridicamente, pode até ser. Na prática, quem montou o app não sabia que tinha que configurar aquilo.

E o problema não está só nas plataformas. O relatório da Veracode de 2025 testou mais de 100 modelos de IA em 80 tarefas de programação: em **45% dos casos** o código gerado tinha falha de segurança, e quando o modelo podia escolher entre um jeito seguro e um inseguro de resolver, escolheu o inseguro quase metade das vezes. A sintaxe melhorou com o tempo. A segurança, não.

## Plataforma ou agente: o risco muda de lugar

Vale separar, porque o cuidado é diferente em cada grupo.

**Nas plataformas (Lovable, v0, Replit, Bolt, Base44)** o risco mora no que fica público: URL aberta, banco sem regra, chave no frontend, app interno indexado. A plataforma faz o deploy por você, e é exatamente isso que faz um protótipo de terça-feira virar um sistema "em produção" sem ninguém ter decidido isso.

**Nos agentes locais (Claude Code, Codex, Cursor)** o risco mora no que o agente pode tocar. É o `.env` com as senhas indo pro repositório público no GitHub, a migration que apaga a coluna errada, o comando rodado direto no servidor, a mudança que ninguém revisou porque "o teste passou". Eu falei da parte viciante de trabalhar com o Claude Code em [Claude Code ou Crack Code?](/blog/claude-code-ou-crack-code); a parte perigosa é a mesma velocidade aplicada sem freio no lugar errado.

O denominador comum é um só: **a ferramenta acelera tudo, inclusive o erro.** E quem está começando nem sabe quais perguntas fazer antes de apertar "publicar".

## Checklist antes de publicar

Se você já tem um app feito com IA no ar, ou está prestes a publicar, passe por esta lista. Não é auditoria de segurança completa, é o mínimo pra não virar estatística:

1. **Toda tabela tem RLS ligada e testada?** Não basta existir uma política. Abra uma janela anônima, sem login, e tente ler os dados. Depois logue como usuário A e tente ver o que é do usuário B.
2. **Nenhum segredo no frontend.** Abra o DevTools, aba Sources, e procure por `key`, `secret`, `token`, `sk_`. Chave de serviço, de pagamento e de IA fica no servidor, sempre.
3. **Cada endpoint confere quem está chamando.** Esconder o botão não protege nada. A API tem que recusar quem não tem permissão.
4. **App interno não fica público.** Senha, login obrigatório ou, no mínimo, `noindex`. E pesquise o seu domínio no Google com `site:` pra ver o que já vazou.
5. **Desenvolvimento e produção separados.** O agente de IA trabalha numa cópia, nunca no banco real.
6. **Backup que você já restaurou uma vez.** Backup que nunca foi testado é só esperança.
7. **Histórico de mudanças.** Git, commits pequenos, e você sabe o que a IA alterou e como voltar.
8. **Dado pessoal tem dono e tem lei.** Se o app guarda nome, CPF, telefone ou dado de saúde, a LGPD vale pra você, mesmo que o app tenha sido feito numa tarde.

Se três ou mais itens dessa lista te fizeram franzir a testa, o próximo bloco é pra você.

## Por que o Tulio criou o VibeCode Pro

Meu amigo [Tulio Faria](https://tuliofaria.dev) tem mais de 20 anos programando, com projetos no Brasil e no exterior, mestrado em Sistemas de Informação pela USP, uma coleção de sistemas e startups criadas e milhares de alunos formados no [DevPleno](https://devpleno.com). Já fiz vários projetos com ele, e é o cara que eu chamo quando o projeto fica complexo.

Ele conta uma história que resume este post inteiro: viu um amigo da área de marketing dando à IA acesso direto ao servidor onde a aplicação dele rodava. A vontade de construir era ótima. Mas as perguntas que a experiência ensina a fazer não estavam ali: se a IA alterar algo errado, como ele vai descobrir? Como vai saber o que mudou? Como recupera o que tinha antes? O que impede uma alteração de apagar os dados?

E o ponto dele é exatamente o meu: **quem está começando nem sabe que precisa fazer essas perguntas.** Foi pra isso que ele criou o [VibeCode Pro](https://do.devpleno.com/vibecode-pro).

> **NOTA**
>
> **Cupom TOLEDO15: 15% de desconto no VibeCode Pro.** O curso sai de R$ 297 por cerca de R$ 252 à vista, ou parcelado em até 12x. [Este link já abre o checkout com o cupom aplicado](https://pay.hub.la/KyOnVsszay0TOEIkgyKr?coupon=TOLEDO15).

### Não é curso de prompt mágico

O que mais gosto na proposta é que ela não vende "faça um SaaS em 10 minutos". Ela vende o que vem **depois** da tela funcionar: conferir, proteger, publicar com critério e continuar evoluindo sem quebrar.

Você explica sua ideia em português (quem vai usar, como precisa funcionar, quais são as regras do negócio) e o Tulio entrega a estrutura e os prompts pra orientar a IA. O fio condutor é um projeto real: um **sistema de agendamento com cobrança**, que é justamente o tipo de app que mexe com dado pessoal e dinheiro, onde o erro custa caro.

### O método em seis passos

1. **Começar pelo template.** Uma estrutura de projeto pronta, com orientações para a IA e uma base para rodar testes. É o equivalente a não começar a casa pelo telhado.
2. **Explicar o que construir, em português.** Os prompts fazem a IA te entrevistar sobre a ideia, os usuários e as regras, e organizar isso num plano antes de sair escrevendo código.
3. **Usar os prompts do método.** Todos os prompts das aulas são entregues pra copiar e adaptar, da construção à revisão e à evolução.
4. **Construir e conferir.** Você orienta a IA e aprende a checar testes e evidências de que cada funcionalidade faz o que foi pedido, em vez de confiar no "pronto, implementei".
5. **Preparar a publicação.** Revisar os caminhos principais da aplicação e, principalmente, **quem pode acessar cada informação**. É aqui que mora boa parte do checklist acima.
6. **Continuar evoluindo.** Revisar mudanças, testar backups e fazer verificações periódicas depois que o app está no ar.

A frase da página que eu assino embaixo: a IA pode cometer erros, pessoas experientes também, e por isso o processo inclui formas de encontrar problemas, reduzir riscos e recuperar o trabalho quando necessário.

### Já fez um app com IA? Dá pra aproveitar

Esse é o detalhe que mais conversa com quem já tem algo no Lovable ou no Replit. O curso tem um prompt que **lê o seu app atual e lista funcionalidades, telas e regras**. Com essa lista, você decide o que manter e reconstrói o projeto sobre o template do curso, agora com testes e proteções desde a base.

A página é honesta sobre o limite: a migração dos dados e a correção do app antigo não estão incluídas. Mas sair de um app que você não sabe se está seguro pra um que você sabe conferir já é outro patamar.

### O que vem no pacote

- Um ano de acesso ao curso
- O template de projeto, com orientações pra IA e base de testes
- Todos os prompts usados no método
- Suporte por e-mail
- Garantia de sete dias

O investimento é de **R$ 297 à vista ou 12x de R$ 30,18**, e com o cupom TOLEDO15 cai mais 15%. Pra comparar: é menos do que um mês de vários planos de ferramenta de IA, e bem menos do que o custo de um único vazamento de dado de cliente.

### Pra quem é (e pra quem não é)

É pra você se:

- é empresário, conhece um problema da sua operação de perto e quer construir a ferramenta que resolve
- repete a mesma tarefa toda semana e enxerga um jeito melhor de trabalhar
- já fez um app com IA e ficou com a pulga atrás da orelha depois deste post
- quer usar Claude Code ou Codex com processo, e não no improviso

Não precisa saber programar nem inglês: você descreve tudo em português e os prompts vêm prontos. Mas precisa acompanhar as aulas, praticar e aprender os conceitos. Não é passe de mágica.

Dois avisos honestos que a própria página dá, e que eu repito porque gosto de curso que não esconde isso: dependendo do volume de uso, você vai precisar de um plano pago de IA (como Claude Code ou Codex), e hospedagem também é à parte. E nenhum processo deixa um app livre de todos os bugs. O que o método faz é te dar formas de testar, revisar e reduzir risco.

> **TIP**
>
> **Vai começar um app com IA agora?** Comece pela estrutura, não pela tela. É muito mais barato decidir quem acessa o quê no primeiro dia do que descobrir pelo Google no décimo. Use o cupom **TOLEDO15** e [entre no VibeCode Pro com 15% de desconto](https://pay.hub.la/KyOnVsszay0TOEIkgyKr?coupon=TOLEDO15).

## Resumo

- Vibe coding é ótimo pra tirar ideia do papel, mas a IA entrega "funcionando", não "protegido".
- Os vazamentos se repetem: banco sem RLS, chave no frontend, API sem checagem e app interno publicado.
- Pesquise `site:lovable.app crm` e veja o tamanho do problema (só olhe, não mexa).
- Antes de publicar: RLS testada, segredo no servidor, ambientes separados, backup restaurado e Git.
- Se você não sabe conferir nada disso, o [VibeCode Pro](https://do.devpleno.com/vibecode-pro) do Tulio ensina o processo, e o cupom TOLEDO15 dá 15% de desconto.

> **NOTE**
>
> Não estou dizendo pra largar o Lovable, o Replit ou o Claude Code. Eu uso IA pra programar todo dia e não volto atrás. O ponto é que a velocidade que a ferramenta te dá precisa vir junto com o processo que um dev experiente aplicaria. Transparência: o Tulio é meu amigo e parceiro de projetos, e o cupom leva o meu nome. Indico porque conheço o trabalho dele de perto.

## Referências

- Matt Palmer. [Statement on CVE-2025-48757](https://mattpalmer.io/posts/statement-on-CVE-2025-48757/)
- Escape. [How we discovered over 2k high-impact vulnerabilities in apps built with vibe coding platforms](https://escape.tech/blog/methodology-how-we-discovered-vulnerabilities-apps-built-with-vibe-coding/)
- The Hacker News. [Wiz Uncovers Critical Access Bypass Flaw in AI-Powered Vibe Coding Platform Base44](https://thehackernews.com/2025/07/wiz-uncovers-critical-access-bypass.html)
- Wiz. [Hacking Moltbook: The AI Social Network Any Human Can Control](https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys)
- eWeek. [AI Agent Wipes Production Database, Then Lies About It](https://www.eweek.com/news/replit-ai-coding-assistant-failure/)
- Veracode. [AI-Generated Code Poses Major Security Risks in Nearly Half of All Development Tasks](https://www.veracode.com/press-release/ai-generated-code-poses-major-security-risks-in-nearly-half-of-all-development-tasks-veracode-research-reveals/)
- Supabase. [Row Level Security](https://supabase.com/docs/guides/database/postgres/row-level-security)
- DevPleno. [VibeCode Pro](https://do.devpleno.com/vibecode-pro)