A Vibe Coding é Segura? Os Riscos Reais e o Que Verificar Antes de Publicar
A vibe coding é segura para ferramentas pessoais e protótipos, e pode ser segura para apps reais com usuários reais, mas só se você acrescentar as verificações que o “é só descrever e ver se funciona” deixa de lado. Os problemas mais perigosos não aparecem na tela: usuários que conseguem abrir os dados uns dos outros, chaves secretas guardadas no navegador e formulários públicos sem limite. Este guia explica os riscos que de fato causam problemas, como lidar com segredos, quanta revisão você precisa e uma verificação de 30 minutos para fazer antes de publicar.
Para a lista técnica completa, veja nossa checklist de segurança para apps criados com IA. Esta página é a versão mais curta e prática, para quem não lê código.
Por que a vibe coding tem riscos próprios
Quando você faz vibe coding, avalia o app usando-o. Isso pega botões quebrados e layouts feios. Não pega problemas que só aparecem quando alguém usa o app de um jeito diferente do seu: um desconhecido, um bot, um usuário curioso editando um endereço web.
Modelos de IA escrevem código plausível, e a maior parte está correta. Mas eles otimizam para o que você pediu — “faça o painel mostrar meus projetos” — e podem não acrescentar a proteção que você não pediu — “e só os meus projetos”. A solução não é parar de fazer vibe coding. É pedir explicitamente as proteções e depois testá-las.
Quão arriscado é o seu app? Uma escala rápida
| Seu app | Risco | O que você precisa |
|---|---|---|
| Uma ferramenta pessoal que só você usa, sem dados sensíveis | Baixo | Manter as chaves fora do código. Só isso. |
| Um site público ou landing page com formulário | Baixo a médio | Limites no formulário, proteção contra bots, nenhum segredo na página |
| Um app em que as pessoas se cadastram e guardam os próprios dados | Médio | Tudo o que está nesta página |
| Pagamentos, dados de saúde, financeiros, de crianças ou documentos de identidade | Alto | Tudo o que está nesta página, mais uma revisão de desenvolvedor |
Seja honesto sobre em qual linha você está. Muitos apps começam na primeira e migram para a terceira sem que ninguém decida isso.
Os riscos que de fato causam problemas
1. Usuários conseguem ver os dados uns dos outros
Este é o problema sério mais comum em apps criados com IA. A página mostra a cada usuário apenas os registros dele, então parece correta. Mas o servidor devolve qualquer registro se alguém trocar o ID na barra de endereço ou em uma requisição. Como você sempre testa como você mesmo, nunca vê isso.
Como verificar: crie duas contas. Entre como usuário A, abra um dos registros de A e anote o endereço. Entre como usuário B em uma janela privada e cole esse endereço. Você deve ver “não encontrado”, nunca os dados de A.
Prompt:
Verifique cada endpoint do servidor que lê, altera ou apaga dados de usuários. Cada um deve confirmar que o usuário logado tem permissão de acessar aquele registro específico. Liste os endpoints, explique como cada um faz essa verificação e corrija os que não fazem.
2. Segredos no lugar errado
Segredo é qualquer coisa que concede acesso: uma chave de API de um serviço de IA ou de e-mail, a senha de um banco de dados, a chave secreta de um provedor de pagamentos. Se ela estiver em código que roda no navegador, qualquer pessoa pode abrir as ferramentas de desenvolvedor e copiá-la. Se for enviada a um repositório público, robôs a encontram em horas.
Como verificar: pergunte à IA.
Liste cada chave de API, token e senha que este app usa. Para cada um, diga onde está guardado e se ele é enviado ao navegador. Mova para segredos do servidor qualquer um que esteja no código ou no frontend.
3. Formulários e endpoints públicos sem limites
Formulários de contato, cadastros e recursos de IA são encontrados por robôs. Sem limites, você recebe spam, contas falsas ou uma conta alta de API de IA por causa de milhares de chamadas.
Prompt:
Adicione limites de requisições para cadastro, login, formulário de contato e todo endpoint que chame um serviço de IA. Adicione um campo honeypot aos formulários públicos. Diga quais limites você escolheu.
4. Confiar no navegador
Tudo o que o navegador decide pode ser alterado pelo usuário: preços, descontos, respostas de quiz, marcações de “é administrador”. Regras que importam precisam ser aplicadas no servidor.
Prompt:
Encontre todo lugar em que o navegador decide algo que deveria ser decidido pelo servidor: preços, totais, permissões, papéis, pontuações. Mova essas verificações para o servidor.
5. Sem como voltar atrás
Uma mudança ruim, ou uma pessoa mal-intencionada, pode apagar dados. Se não há backup nem como reverter, um pequeno erro se torna permanente. Garanta que sua ferramenta tenha checkpoints para o código e backups para o banco de dados. Veja como fazer backup do banco de dados do seu app.
Como lidar com segredos da forma certa
Segredos causam mais danos evitáveis do que qualquer outra coisa, então aqui estão as regras reunidas:
- Nunca cole uma chave real no chat. Conversas ficam armazenadas, são compartilhadas e capturadas em tela. Coloque as chaves nos segredos ou nas variáveis de ambiente da sua ferramenta. (O que são variáveis de ambiente e segredos.)
- Chame serviços pagos a partir do servidor. O navegador pede ao seu servidor; o servidor chama o serviço de IA ou de pagamento com a chave.
- Use chaves separadas para testes e para uso real, para que uma chave de teste vazada não toque em dinheiro de verdade.
- Defina limites de gasto nos painéis dos provedores de IA e de e-mail.
- Troque uma chave imediatamente se achar que ela vazou. Crie uma nova, atualize o segredo e então apague a antiga.
No Mythex, os segredos ficam nas configurações do projeto, fora do código, e o agente pode usá-los sem que os valores apareçam no chat. Nosso guia sobre como manter as chaves de API seguras cobre mais provedores.
Quanta revisão de código você precisa?
Na vibe coding, você não lê cada linha. Não precisa. Mas, em algumas partes, alguém deveria ler.
- Ferramentas pessoais: nada além das verificações deste guia.
- Apps com contas de usuário: revise como o login e o acesso aos dados funcionam. Você pode fazer isso pedindo à IA que explique em palavras simples e conferindo se a explicação bate com o que você espera.
- Apps com pagamentos ou dados sensíveis: peça a um desenvolvedor que analise autenticação, permissões, o tratamento de pagamentos e qualquer parte que guarde dados pessoais. São algumas horas de trabalho dele, não uma reescrita.
Um prompt útil mesmo sem um desenvolvedor:
Explique, em palavras simples, como este app decide quem é o usuário e o que ele pode ver. Aponte os arquivos. Depois liste o que você gostaria que um revisor de segurança analisasse.
Nosso guia sobre como revisar código gerado por IA explica o que os revisores procuram, e você pode entregá-lo a quem fizer a revisão. Se a sua ferramenta permite exportar o código ou sincronizar com o GitHub, combinar essa revisão é fácil; no Mythex, as duas coisas fazem parte do Pro.
A verificação de 30 minutos antes de publicar
Faça isto antes de compartilhar o link com alguém fora do seu círculo.
Acesso (10 minutos)
- Duas contas, dois navegadores: o usuário B consegue abrir os registros do A pela URL? Não deveria.
- Saia da conta e acesse diretamente o endereço de cada página. Páginas privadas devem mandar você para o login.
- Como usuário comum, tente abrir endereços de administração. Eles devem ser recusados.
Segredos (5 minutos)
- Pergunte à IA onde fica cada chave, usando o prompt acima.
- Abra o app, veja o código-fonte da página e procure por “key”, “secret” e “token”.
Formulários e abuso (5 minutos)
- Envie cada formulário vazio, com textos muito longos e duas vezes em sequência rápida.
- Confirme que existem limites de requisições no cadastro, no login e em qualquer recurso de IA.
Dados e recuperação (5 minutos)
- Saiba onde os dados ficam e como restaurá-los.
- Confira se é possível voltar o código para uma versão anterior que funcionava.
Jurídico e básicos (5 minutos)
- Se você coleta dados pessoais, adicione uma política de privacidade e diga o que coleta. Veja como escrever termos de uso e uma política de privacidade.
- Confirme que o app publicado usa HTTPS. A maioria dos criadores, o Mythex incluído, cuida disso para você.
Se tudo passar, você está em boa forma para um lançamento inicial. Repita os passos 1 a 5 depois de qualquer mudança grande em login, papéis ou dados.
O que as plataformas de vibe coding protegem e o que não protegem
Uma boa plataforma cuida de boa parte da infraestrutura: HTTPS, workspaces isolados, um banco de dados por projeto, armazenamento de segredos, backups e reversão. O Mythex dá a cada projeto um workspace privado e um banco de dados próprios, mantém os segredos fora do código e salva um checkpoint depois de cada mudança bem-sucedida, para que você possa desfazê-la.
O que nenhuma plataforma consegue é conhecer as regras do seu app. Só você sabe que clientes não devem ver as faturas uns dos outros, ou que um cupom deve funcionar uma única vez. Essas regras precisam estar nos seus prompts e ser confirmadas pelos seus testes.
A resposta curta
A vibe coding é tão segura quanto as verificações que você acrescenta. Para uma ferramenta pessoal, mantenha as chaves fora do código e aproveite. Para qualquer coisa com dados de outras pessoas, faça a verificação de 30 minutos acima antes de cada lançamento e peça o olhar de um desenvolvedor para pagamentos e dados sensíveis. Para ver esses riscos em projetos reais, leia nossos exemplos de vibe coding; para construir já com essas verificações, siga como criar um app com vibe coding.
Perguntas
A vibe coding é segura?
É segura para ferramentas pessoais e protótipos sem dados sensíveis. Para apps em que outras pessoas se cadastram, guardam dados ou pagam, ela só é segura se você acrescentar as verificações que a vibe coding deixa de lado: regras de acesso no servidor, segredos fora do código, limites para formulários públicos e uma revisão de tudo o que lida com dinheiro ou dados pessoais.
Qual é o maior risco de segurança em apps feitos com vibe coding?
Controle de acesso quebrado: um usuário logado consegue ler ou alterar os dados de outro, geralmente trocando um ID em uma requisição. Isso nunca aparece quando você testa como você mesmo, e é por isso que é tão comum. Teste de propósito com duas contas.
Código gerado por IA pode vazar minhas chaves de API?
Pode, se a chave acabar em um código que roda no navegador do visitante ou for enviada a um repositório público. Guarde as chaves nos segredos ou nas variáveis de ambiente da sua ferramenta, chame serviços externos a partir do servidor e peça à IA uma lista de onde cada chave é usada.
Preciso de um desenvolvedor para revisar um app feito com vibe coding?
Não para uma ferramenta pessoal ou um protótipo inicial. Peça a revisão de um desenvolvedor antes de aceitar pagamentos diretamente, guardar dados de saúde, financeiros ou de crianças, ou abrir o app para muitos usuários. Acesso à exportação ou ao GitHub facilita essa revisão.
Meu código e meus dados estão seguros em uma plataforma de vibe coding?
Depende da plataforma, então leia as páginas de segurança e de privacidade dela. No Mythex, cada projeto roda em um workspace privado próprio, com banco de dados próprio; os segredos ficam fora do código; e os checkpoints permitem desfazer uma mudança ruim. A lógica do seu app ainda precisa das verificações deste guia.