A Violação do Moltbook: Quando o Vibe Coding Se Torna um Pesadelo de Segurança
Segurança

A Violação do Moltbook: Quando o Vibe Coding Se Torna um Pesadelo de Segurança

A violação do Moltbook expôs 1,5 milhão de chaves de API após uma plataforma codificada por vibe hardcodear credenciais do Supabase em JavaScript do lado do cliente. Aqui está o que deu errado, por que importa e como proteger seu código gerado por IA.

Por Equipe GetFree·19 de fevereiro de 2026·5 min de leitura

A Violação do Moltbook: Quando o Vibe Coding Se Torna um Pesadelo de Segurança

O que realmente aconteceu no Moltbook?

Deixe-me explicar exatamente o que deu errado, porque os detalhes importam.

Moltbook foi construído usando Supabase — uma popular alternativa open-source ao Firebase que fornece bancos de dados PostgreSQL hospedados. O Supabase se tornou o backend de escolha para aplicativos criados com vibe coding porque lida com autenticação, bancos de dados e armazenamento com configuração mínima.

O problema? Alguém (ou alguma IA) colocou uma chave de API do Supabase diretamente no código JavaScript do lado do cliente. Este é um erro fundamental de segurança. Chaves de API pertencem ao servidor, nunca em código que roda no navegador do usuário.

Mas piora.

Essa chave de API tinha acesso total de leitura e gravação a todo o banco de dados. E o Moltbook não havia habilitado Segurança em Nível de Linha (RLS) — um recurso do Supabase que controla quem pode acessar quais dados. RLS é tão opcional quanto um cinto de segurança. Você pode pensar que não precisa até bater.

Pesquisadores de segurança da Wiz encontraram a chave exposta em minutos após olhar o site. Eles poderiam:

  • Baixou todas as 1,5 milhão de chaves de API (incluindo chaves para OpenAI, Anthropic e outros provedores de IA)
  • Acessou mensagens privadas entre agentes de IA
  • Modificou ou deletou qualquer dado no banco de dados
  • Sequestrou qualquer conta de usuário
  • Gere contas enormes usando chaves de API roubadas

O ponto crucial? O fundador admitiu que ele "completamente vibe-coded" toda a plataforma. Sem revisão de código. Sem auditoria de segurança. Apenas prompts para uma IA e copiando e colando os resultados.

Por Que Isso Continua Acontecendo

Aqui está o que é frustrante sobre esta história: não é única.

Lembra quando DeepSeek teve suas chaves de API expostas? Ou Base44? O padrão se repete porque a filosofia de vibe coding desencoraja ativamente as práticas que previnem essas violações.

A filosofia central da programação por vibe é: mova-se rápido, foque nos resultados, não se preocupe com os detalhes. É sedutora porque — honestamente — funciona para construir protótipos. Você pode criar um aplicativo funcional em horas.

Mas aplicações de produção vivem em um mundo diferente. Elas lidam com dados reais de usuários, pagamentos reais, ameaças de segurança reais. A mesma mentalidade que ajuda você a enviar um protótipo em um fim de semana fará com que seu aplicativo de produção seja hackeado no primeiro dia.

Falei com um pesquisador de segurança que se especializa em código gerado por IA. Eis o que o mantém acordado à noite:

  • Sem entendimento do que está acontecendo: Quando você pede a uma IA para "criar um sistema de login", você recebe código que parece um sistema de login, mas pode ter falhas sutis que apenas um especialista notaria
  • Confiar na IA: Usuários assumem que o código gerado por IA é seguro porque... é de uma IA? Essa suposição está completamente errada
  • Faltando fundamentos: Desenvolvedores de vibe coding frequentemente não sabem o que não sabem sobre segurança

O Problema dos 45%

Deixe-me dar um número que deve te manter acordado à noite: 45%.

Essa é a porcentagem de código gerado por IA que contém vulnerabilidades de segurança, de acordo com a pesquisa da Veracode sobre segurança de software gerado por IA[1].

Isso não se trata de modelos de IA ruins ou desenvolvedores incompetentes. Trata-se da natureza fundamental da geração de código. Modelos de IA são treinados em código existente — o que inclui código inseguro. Eles reproduzem padrões que viram, incluindo os vulneráveis.

Vulnerabilidades comuns em código gerado por IA incluem:

VulnerabilidadeO Que SignificaImpacto no Mundo Real
Injeção de SQLAtacantes podem executar comandos maliciosos de banco de dados4.000 caracteres
XSS (Cross-Site Scripting)Atacantes podem injetar scripts maliciososSequestro de sessão, roubo de dados
Segredos codificadosChaves de API, senhas no códigoInvasões de contas, cobranças infladas
Validação de Entrada AusenteSem verificação de entradas do usuárioAtaques de injeção, falhas
Autenticação InseguraImplementação fraca de loginAcesso não autorizado

A violação do Moltbook foi na verdade dois problemas: uma chave de API hardcoded (segredos hardcoded) E RLS ausente (configuração insegura). Qualquer um sozinho já seria ruim. Juntos, criaram uma catástrofe.

O Que Ninguém Te Conta Sobre Vibe Coding

Seja real com você mesmo. Eu já fiz vibe coding de muitos projetos. Isso realmente mudou a forma como construo coisas. Mas também aprendi algumas lições difíceis da maneira difícil.

Você ainda precisa entender segurança

Aqui está uma verdade desconfortável: você não pode usar ferramentas de IA para construir aplicações seguras se você não entender segurança por si mesmo. A IA não conhece seu modelo de ameaça. Ela não sabe quais ativos você está protegendo. Ela apenas gera código que parece razoável.

Você não precisa se tornar um especialista em segurança. Mas precisa entender:

  • Nunca coloque segredos no código do lado do cliente
  • Sempre habilite Segurança em Nível de Linha em bancos de dados
  • Use variáveis de ambiente para configuração sensível
  • Implemente validação de entrada adequada
  • Executar varreduras de segurança no código gerado

Prototipe Rápido, Depois Engenheire

Meu fluxo de trabalho atual:

  • Code o protótipo com vibe — Algo funcionando, valide a ideia com usuários reais
  • Identifique o produto-mercado fit — Antes de investir em qualquer coisa
  • Refatore para produção — É aqui que você realmente engineeringa a segurança, performance e manutenibilidade

O erro é enviar protótipos codificados por vibe diretamente para produção sem a etapa de refatoração. Você não está economizando tempo — está acumulando dívida técnica que custará caro depois.

Use a Ferramenta Certa para o Trabalho

Isso pode ser controverso, mas não acho que vibe coding seja apropriado para:

  • Aplicações que lidam com dados sensíveis do usuário (saúde, finanças)
  • Sistemas que processam pagamentos
  • Qualquer coisa com requisitos de conformidade regulatória
  • Aplicações onde falhas de segurança poderiam causar danos reais

Para ferramentas internas, MVPs e protótipos? Solte a criatividade. Para sistemas de produção lidando com dados reais de usuários? Engenheire adequadamente.

Como se proteger

Se você está fazendo vibe coding de qualquer forma (e honestamente, deveria — é incrivelmente poderoso), aqui está como evitar se tornar a próxima manchete:

Para Seu Supabase/Backend

javascript
// WRONG - Never do this const supabase = createClient('https://xxx.supabase.co', 'YOUR_ANON_KEY_HERE') // Your service_role key is also exposed here! // CORRECT - Use environment variables, server-side only const supabase = createClient( process.env.SUPABASE_URL, process.env.SUPABASE_ANON_KEY )

Lista de Verificação de Segurança Essencial

  • [ ] Ativar Segurança em Nível de Linha em TODAS as tabelas do banco de dados
  • [ ] Armazene chaves de API da loja em variáveis de ambiente, nunca no código
  • [ ] Execute uma verificação de segurança em todo o código gerado (Snyk, CodeQL ou GitHub Advanced Security)
  • [ ] Nunca exponha chaves service_role ao cliente
  • [ ] Implementar validação de entrada adequada em todas as entradas do usuário
  • [ ] Configure limitação de taxa para prevenir abuso
  • [ ] Faça um teste de penetração antes de lançar qualquer coisa com usuários reais

Ferramentas Que Ajudam

FerramentaO que ele fazPlano Gratuito
SnykVerificação de segurança de códigoSim
GitHub Advanced SecurityDetecção de vulnerabilidadesSim (para repositórios)
StackHawkTeste de segurança de APISim
DependabotVulnerabilidades de dependênciaSim

O Que Isso Significa para a Indústria

Estou genuinamente preocupado com o rumo que estamos tomando.

Estamos no meio de uma mudança massiva na forma como o software é construído. Fundadores não técnicos agora podem criar aplicativos sofisticados. A barreira de entrada desabou. Isso é genuinamente empolgante.

Mas também estamos criando uma geração de aplicações com ninguém vigiando a loja.

Aqui está o que eu acho que precisa acontecer:

  • Ferramentas de codificação com IA precisam de padrões de segurança melhores — Pare de gerar código com vulnerabilidades embutidas
  • Comunidades precisam falar mais sobre isso — Cada postagem de blog sobre vibe coding deve mencionar segurança
  • Precisamos de melhores ferramentas — A varredura de segurança automatizada deve ser incorporada em cada fluxo de trabalho de codificação com IA
  • Fundadores precisam assumir responsabilidade — Você não pode culpar a IA quando algo dá errado

O futuro do desenvolvimento de software não é escolher entre velocidade de IA e segurança. É aprender a usar ambos juntos.

Perguntas Frequentes

As ferramentas de IA não podem corrigir problemas de segurança?

Eles podem e estão melhorando. Mas os modelos de IA são treinados em código existente — o que inclui código inseguro. Eles estão essencialmente aprendendo maus hábitos de todo o corpus de software humano. Estamos começando a ver modelos especificamente treinados em código seguro, mas ainda não chegamos lá.

As ferramentas de IA não podem corrigir problemas de segurança?

O Supabase é aceitável quando configurado corretamente. O problema não era o Supabase — era a configuração do Moltbook (ou falta dela). O Supabase tem excelentes recursos de segurança (como Segurança em Nível de Linha). O problema foi que a codificação por impulso levou a pular esses recursos.

O Supabase não é seguro?

Absolutamente não. É uma maneira incrivelmente poderosa de construir e iterar. Apenas entenda que "foi vibe coded" não é desculpa para falhas de segurança. Prototipe rápido, valide sua ideia, então engenheire para produção.

Devo parar de vibe coding?

Desenvolvimento tradicional com práticas focadas em segurança. Ou: aprenda o suficiente para revisar o código gerado pela IA você mesmo. Ou: contrate alguém para fazer uma auditoria de segurança antes do lançamento. Ou: use ferramentas e frameworks com padrões de segurança fortes integrados.

Qual é a alternativa ao vibe coding?

A Visão Geral

Moltbook não é uma anomalia. É uma prévia do que está por vir.

À medida que mais fundadores enviam aplicações codificadas por vibe sem compreender fundamentos de segurança, veremos mais violações. Mais chaves API vazadas. Mais bancos de dados expostos. Mais vítimas.

Isso não é um argumento contra vibe coding. É um argumento para ser honesto sobre suas limitações.

Envie rápido. Teste ideias. Mova-se rapidamente. Mas antes de colocar dados reais de usuários em risco, diminua o ritmo e faça o trabalho de segurança. Seus usuários estão confiando em você com suas informações. Essa confiança não deve ser vibe-codificada.

Postagens Relacionadas

Pronto para lançar seu app com segurança? Liste seu app na GetFree—um diretório curado onde desenvolvedores compartilham códigos promocionais e acesso beta com milhares de testadores direcionados.

Fontes

Originalmente publicado no Blog GetFree.APP — Última atualização: 17 de Fevereiro de 2026

Gostou deste artigo? Compartilhe com outros!

Compartilhar:

Pronto para descobrir apps incríveis?

Encontre e compartilhe os melhores apps gratuitos de iOS com GetFree.APP

Começar