Vibe Coding é seguro? O que saber antes de lançar

Resposta direta

Vibe Coding é seguro quando o código gerado é tratado com o mesmo rigor de qualquer código de produção, escrito por humano ou por IA. Não é seguro por padrão, e também não é inseguro por padrão: a segurança não vem da ferramenta usada para gerar o código, vem da revisão que acontece (ou não acontece) antes de esse código chegar perto de dados reais.

Essa resposta incomoda quem espera um “sim” ou “não” simples, mas é a única honesta. Um assistente de IA pode gerar autenticação, validação e controle de acesso corretos, porque já viu milhares de exemplos desses padrões durante o treinamento. O mesmo assistente também pode gerar uma chave de API exposta no código do navegador, ou uma tabela sem nenhuma restrição de acesso, porque não tem como saber, sozinho, quais dados daquele projeto específico são sensíveis e quais não são. Esse julgamento continua sendo trabalho humano, e é sobre esse trabalho que este artigo trata.

Os riscos reais

Alguns padrões de falha se repetem com frequência suficiente em projetos de Vibe Coding para merecer atenção nomeada, cada um com o tipo de sinal que indica o problema, sem entrar em como alguém exploraria a falha na prática.

Chaves expostas. É comum uma chave de API, token de serviço externo ou credencial de banco de dados acabar direto num arquivo que roda no navegador do usuário, porque naquele momento do desenvolvimento “só precisava funcionar”. O sinal de alerta é qualquer credencial visível ao inspecionar o código-fonte que chega ao cliente, ou versionada em algum commit do repositório, mesmo que tenha sido removida depois: remover do arquivo atual não remove do histórico do Git.

RLS ausente ou incompleta. Em bancos como o Supabase, a ausência de Row Level Security, ou a presença de RLS ativado sem policies específicas por operação, deixa dados acessíveis diretamente pela API do banco, sem passar pela aplicação. O sinal de alerta é qualquer tabela com dado de usuário sem policy testada explicitamente para cada tipo de operação (leitura, escrita, atualização, exclusão).

Dependências desatualizadas ou não revisadas. Projetos gerados rápido acumulam bibliotecas de terceiros com a mesma velocidade que acumulam funcionalidade, e nem toda dependência instalada automaticamente passa por revisão de origem ou de versão. O sinal de alerta é um projeto que nunca rodou uma auditoria de dependências (a maioria dos gerenciadores de pacote tem esse comando embutido) desde o início do desenvolvimento.

Injeção de dados não validados. Quando entrada do usuário é usada para montar uma consulta ao banco ou um comando sem passar por validação e sanitização apropriadas, existe risco de injeção, uma das falhas mais antigas e mais conhecidas em software. O sinal de alerta é qualquer campo de entrada do usuário indo direto para uma consulta sem passar por uma camada de validação e por parâmetros preparados, em vez de concatenação direta de texto.

Dados pessoais e LGPD. Projetos que coletam dado pessoal (nome, e-mail, documento, localização, comportamento de uso) sem base legal clara, sem possibilidade de o usuário solicitar exclusão, ou sem cuidado redobrado com dado sensível, expõem o negócio a risco regulatório, além do risco técnico. O sinal de alerta é não conseguir responder, com clareza, “que dado pessoal coletamos, por quê, e como um usuário pede para apagar o dele”.

Vale reforçar o que este artigo não é: não é um manual de como explorar nenhuma dessas falhas. A lista acima existe para você reconhecer o padrão no seu próprio projeto e levar para revisão, do mesmo jeito que uma lista de sintomas ajuda a procurar um médico, não a se autodiagnosticar sem apoio. Cada um desses riscos tem tratamento técnico conhecido e bem documentado, e boa parte das plataformas usadas em Vibe Coding, como Supabase, já oferece o mecanismo de defesa embutido (RLS é o exemplo mais direto). O trabalho que falta é ativar, configurar e testar, não inventar a solução do zero.

O que a IA erra em segurança com frequência

Vale entender o padrão, não só a lista de riscos. Assistentes de IA são muito bons em reproduzir soluções comuns e bem documentadas: um formulário de login segue um padrão conhecido, então sai correto na maioria das vezes. O problema aparece em decisões que dependem de contexto específico do seu produto, que a IA não tem como inferir sozinha: quais dados são sensíveis nesse projeto em particular, qual usuário deveria ter acesso a qual recurso, o que acontece se dois usuários tentarem editar o mesmo registro ao mesmo tempo.

Outro padrão de erro comum é a IA otimizar para “o caminho feliz funcionar na demonstração”, o que é natural dado como esses sistemas são usados no dia a dia: você pede uma funcionalidade, testa se ela funciona, segue em frente. Validação de entrada malformada, tentativa de acesso não autorizado, comportamento sob concorrência, nada disso aparece espontaneamente num teste manual rápido, e por isso tende a ficar de fora do que a IA prioriza sem instrução explícita para cobrir esses casos.

Vale também reconhecer que esse padrão de erro não é exclusivo de nenhuma ferramenta específica de Vibe Coding. Aparece em código gerado por qualquer assistente, e aparece também em código escrito à mão por desenvolvedores sob pressão de prazo. A diferença prática é a velocidade: como a IA gera código muito mais rápido do que um time consegue revisar linha por linha, o volume de código não revisado tende a crescer mais rápido também, se a revisão não for tratada como etapa formal do processo.

Uma forma prática de reduzir esse risco, sem abrir mão da velocidade que torna o Vibe Coding atraente, é pedir explicitamente, na hora de gerar cada funcionalidade sensível, que a IA cubra os casos de borda relevantes: o que acontece com entrada inválida, com usuário não autenticado, com tentativa de acessar dado de outra pessoa. Assistentes de IA respondem bem quando o contexto pede isso de forma explícita, porque o padrão existe no que foram treinados, só não aparece por padrão sem ser solicitado. Não é uma garantia de segurança completa, mas reduz consideravelmente a distância entre “funciona na demonstração” e “aguenta uso adverso”.

Checklist mínimo de segurança para projetos de Vibe Coding

Antes de qualquer usuário real acessar o produto, valem estes pontos como piso mínimo, não como lista completa:

• Nenhuma chave ou credencial sensível aparece no código que roda no navegador do usuário.
• RLS ativado, com policy testada, em toda tabela que guarda dado de usuário.
• Autenticação confirma quem é o usuário, e autorização, testada explicitamente, confirma o que cada um pode ver e fazer.
• Toda entrada do usuário passa por validação antes de chegar ao banco de dados ou a qualquer lógica de negócio.
• Dependências do projeto passaram por auditoria de segurança recente, não instaladas e esquecidas.
• Existe resposta clara para “que dado pessoal coletamos e como o usuário pede para apagar o dele”, alinhada com a LGPD.
• Backup do banco de dados existe e já foi testado com uma restauração real, não só configurado e esquecido.

Esse checklist não substitui uma auditoria de segurança completa em produtos com dado sensível ou volume relevante de usuários, mas cobre o piso que qualquer projeto deveria ter antes de aceitar tráfego real. Tratamos boa parte desses pontos, incluindo o que revisar especificamente em Supabase e Postgres, no artigo sobre banco de dados em projetos de Vibe Coding, e a auditoria completa de protótipo até produção está detalhada no artigo sobre levar um protótipo de IA até a produção.

Quem responde quando dá errado

Uma pergunta que poucos fundadores fazem antes de precisar da resposta: se um incidente de segurança expõe dado de cliente, quem responde por isso? A ferramenta de Vibe Coding usada para gerar o código não assume essa responsabilidade, nem deveria, da mesma forma que um editor de texto não responde pelo conteúdo escrito nele. A responsabilidade final é de quem opera o produto e decidiu, em algum momento, aceitar o código gerado sem revisar essa frente específica.

Isso não é motivo para medo, é motivo para tratamento sério. Empresas que colocam produto em produção profissionalmente, com ou sem IA no processo de construção, assumem esse tipo de responsabilidade como parte do negócio, com processo de revisão, resposta a incidente definida com antecedência e, na maioria dos casos, algum tipo de seguro ou cláusula contratual que trata o cenário de falha. Um projeto de Vibe Coding que já tem clientes pagando por ele merece esse mesmo nível de tratamento, não um tratamento mais leniente só porque a velocidade de construção foi maior.

Um fundador técnico costuma entender essa responsabilidade de forma intuitiva, mas quem veio de outra área e usou Vibe Coding justamente para não depender de um time de engenharia no início nem sempre tem esse instinto formado. Não é falha pessoal, é falta de exposição prévia ao tipo de decisão que engenheiros experientes tomam quase sem pensar depois de anos vendo o que dá errado. Reconhecer essa lacuna e buscar revisão externa antes do incidente, não depois, é o tipo de decisão que separa fundadores que escalam com segurança dos que aprendem essa lição da forma mais cara possível.

Conclusão

Vibe Coding é seguro na mesma medida em que qualquer método de desenvolvimento de software é seguro: depende inteiramente da disciplina aplicada antes do lançamento, não da ferramenta escolhida para escrever o código. Chaves expostas, RLS ausente, dependências não revisadas, entrada não validada e tratamento inadequado de dado pessoal são riscos reais, conhecidos e, o mais importante, evitáveis com um processo de revisão que trate segurança como etapa formal, não como algo a se resolver se sobrar tempo antes do lançamento.

Se o seu projeto de Vibe Coding já está construído e você quer uma revisão de segurança séria antes de lançar ou escalar, converse com a MVP Plus sobre o Vibe Squad.