O app nasce em três dias. O founder demonstra na reunião na sexta-feira. Os investidores ficam impressionados com a velocidade. Na segunda-feira, os primeiros usuários fazem cadastro e inserem seus dados. Na quarta-feira, alguém com conhecimento técnico básico acessa o banco de dados inteiro sem autenticação.
Esse roteiro não é hipotético. É o padrão documentado em centenas de aplicações construídas com plataformas de vibe coding ao longo de 2025. A velocidade de construção não é o problema. O problema é que segurança e compliance não são consequências automáticas de um app funcional. São propriedades que precisam ser construídas com intenção.
A plataforma de vibe coding entregou um app que funciona. Não entregou um app seguro. A diferença entre os dois é o que este artigo explica.
1. Por que a IA gera código inseguro de forma consistente
O problema não é ignorância, é contexto
A IA generativa conhece os conceitos de segurança. Se você perguntar a qualquer modelo de linguagem atual o que é SQL Injection, ela vai explicar com precisão e até mostrar exemplos de código vulnerável e código seguro. O problema não é que a IA não sabe o que é segurança.
O problema é que quando a IA gera código para um app específico, ela não tem o contexto completo do sistema que está sendo construído. Ela não sabe quem vai usar esse app, que tipo de dados vão ser armazenados, qual é o modelo de ameaça relevante para esse negócio específico, quais são os requisitos regulatórios do setor.
Ela gera código que funciona para o caso descrito no prompt. Segurança para casos não descritos no prompt é invisível para ela. E a maioria dos prompts de vibe coding não menciona segurança. Menciona funcionalidade.
O padrão de treinamento reproduz o passado
Os modelos de linguagem são treinados em código existente. E o código existente na internet inclui uma quantidade enorme de código inseguro. Padrões de autenticação client-side que eram comuns antes de maturação das melhores práticas. Queries sem parametrização. Configurações de banco de dados com permissões abertas.
Quando a IA gera código similar ao que viu durante o treinamento, ela reproduz esses padrões junto com o código funcional. Não com má intenção. Porque esses padrões fazem parte da distribuição de código que ela aprendeu a imitar.
O Veracode analisou aplicações com alta proporção de código gerado por IA e encontrou XSS em 86% dos casos e Log Injection em 88%. São vulnerabilidades clássicas que aparecem em código IA com frequência muito superior ao código escrito por desenvolvedores experientes.
A ilusão do código que funciona
A característica mais traiçoeira das vulnerabilidades em código gerado por IA é que elas não impedem o app de funcionar. Um app com RLS ausente carrega, autentica usuários, mostra dados na tela e parece completamente normal durante os testes iniciais. A vulnerabilidade só se manifesta quando alguém tenta explorá-la.
Isso cria uma armadilha cognitiva: o founder testa o app, tudo funciona, conclui que está pronto para usuários reais. O que ele testou foi o happy path funcional. O que não foi testado foi a superfície de ataque.
2. As vulnerabilidades mais comuns em apps vibe-coded
A tabela abaixo reúne as vulnerabilidades documentadas com maior frequência em aplicações construídas com plataformas de vibe coding, com base nos estudos do Escape.tech, Wiz Research, CodeRabbit e Apiiro publicados em 2025.
Vulnerabilidade | Frequência em código IA | Impacto potencial | Mitigação mínima |
RLS ausente ou mal configurado | Muito alta | Exposição total do banco de dados | Revisar cada política RLS antes do deploy |
XSS (Cross-Site Scripting) | Alta — 86% | Roubo de sessão, injeção de conteúdo | Content Security Policy + sanitização de inputs |
SQL Injection | Alta | Acesso e manipulação do banco | Queries parametrizadas, ORM com prepared statements |
Autenticação client-side | Alta | Bypass de controle de acesso | Validação sempre no servidor, nunca só no cliente |
Secrets hardcoded | Média | Exposição de chaves API e credenciais | Variáveis de ambiente, nunca no código-fonte |
Rate limiting ausente | Muito alta | Abuso, DDoS, brute force | Rate limiting em todos os endpoints públicos |
IDOR (Insecure Direct Object Ref.) | Média-alta | Acesso a dados de outros usuários | Verificar autorização em toda operação de dado |
Log Injection | Alta — 88% | Manipulação de logs, ocultação de ataques | Sanitizar dados antes de incluir em logs |
CORS mal configurado | Média | Requisições de origens não autorizadas | Allowlist explícita de origens confiáveis |
Dados sensíveis em URL | Média | Exposição em logs de servidor e histórico | Dados sensíveis somente no body, nunca na URL |
RLS ausente: a vulnerabilidade mais comum e mais perigosa
Row Level Security (RLS) é o mecanismo do Supabase que controla quais linhas de dados cada usuário pode acessar. Quando configurado corretamente, um usuário autenticado só consegue ler e modificar os dados que pertencem a ele. Quando ausente ou mal configurado, qualquer usuário autenticado pode acessar os dados de todos os outros usuários.
O Matt Palmer analisou 1.645 aplicações construídas com Lovable em 2025 e encontrou que 10,3% tinham RLS ausente ou mal configurado. Isso significa que qualquer usuário dessas aplicações podia, com uma query simples, ler o banco de dados inteiro. Nomes, e-mails, dados financeiros, histórico de transações. Tudo acessível.
O Lovable gera projetos com Supabase por padrão. O Supabase exige configuração manual do RLS. A IA gera a estrutura do banco mas não configura as políticas de segurança com a especificidade necessária para cada caso. O resultado é previsível.
Autenticação client-side: parece seguro, não é
O Wiz Research cunhou a expressão "authentication theater" para descrever um padrão frequente em apps gerados por IA: a verificação de permissões acontece no frontend, no código que roda no browser do usuário, não no servidor que controla os dados.
Um usuário normal não percebe a diferença. Mas qualquer pessoa com acesso ao DevTools do browser consegue inspecionar as requisições que o app faz ao backend, identificar os endpoints de dados e fazer chamadas diretas a eles, sem passar pela verificação de autenticação que existe apenas no frontend.
A IA gera esse padrão com frequência porque é o caminho mais simples para fazer algo que parece funcionar. A segurança real exige que a validação aconteça no servidor, para cada requisição, verificando se o usuário autenticado tem permissão para acessar aquele dado específico.
Secrets hardcoded: o erro que vive no histórico do git
Chaves de API, tokens de acesso, credenciais de banco de dados inseridas diretamente no código-fonte. A IA comete esse erro com regularidade porque o prompt frequentemente inclui informações de configuração e a IA as incorpora no código da forma mais direta possível.
O problema não é apenas que o secret está no código. É que o código vai para um repositório git. E o git guarda o histórico. Mesmo que você remova o secret em um commit posterior, ele continua no histórico e pode ser recuperado por qualquer pessoa com acesso ao repositório. O Escape.tech encontrou mais de 400 secrets expostos em um único lote de 5.600 aplicações vibe-coded analisadas.
3. LGPD e apps brasileiros: o que a lei exige que a IA não entrega
A LGPD não é opcional e não tem prazo de carência para startups
A Lei Geral de Proteção de Dados entrou em vigor no Brasil em setembro de 2020 e se aplica a qualquer organização que colete, armazene ou processe dados pessoais de pessoas físicas localizadas no Brasil. Não importa o tamanho da empresa. Não importa se é uma startup em fase inicial. Se você coleta e-mail de usuário, você está sujeito à LGPD.
As sanções são proporcionais ao faturamento e podem chegar a 2% da receita bruta anual da empresa, limitadas a R$ 50 milhões por infração. Mas o impacto reputacional de um vazamento notificado à ANPD pode ser mais custoso do que a multa em si, especialmente para empresas que dependem de confiança para crescer.
Um app vibe-coded que coleta dados de usuários brasileiros sem os controles adequados não é apenas tecnicamente vulnerável. É legalmente não conforme desde o primeiro cadastro.
O que a LGPD exige e o que a IA normalmente entrega
A tabela abaixo mapeia os principais requisitos da LGPD com o que plataformas de vibe coding tipicamente geram e o que precisa ser adicionado manualmente antes de qualquer lançamento para usuários reais.
Requisito LGPD | O que a IA normalmente gera | O que você precisa adicionar |
Consentimento explícito | Formulário sem campo de consentimento ou com checkbox pré-marcado | Consentimento granular, registrado com timestamp e versão de política |
Finalidade declarada | Coleta dados sem declarar para que servem | Política de privacidade linkada antes da coleta, finalidade documentada |
Minimização de dados | Coleta todos os campos que parecem úteis | Coletar apenas o mínimo necessário para a finalidade declarada |
Direito de acesso e exclusão | Sem mecanismo para o titular acessar ou excluir seus dados | Endpoint funcional de acesso e exclusão de dados por titular |
Segurança dos dados | RLS básico ou ausente, sem criptografia em trânsito verificada | Criptografia em repouso e em trânsito, RLS revisado por especialista |
Notificação de incidentes | Sem processo de detecção ou notificação de vazamentos | Monitoramento de acesso anômalo e processo de notificação à ANPD |
Transferência internacional | Pode usar serviços fora do Brasil sem declaração | Mapear onde os dados são processados, garantir adequação ou cláusulas contratuais |
Registro de atividades | Sem logs de acesso a dados pessoais | Logs de quem acessou quais dados, quando e com qual finalidade |
O consentimento que a IA não implementa corretamente
O requisito de consentimento da LGPD é mais específico do que a maioria dos founders percebe. Não basta ter uma checkbox "li e aceito os termos". O consentimento deve ser livre (sem pressão), informado (o usuário sabe exatamente para que está consentindo), inequívoco (sem ambiguidade) e específico para cada finalidade de tratamento.
Aplicações geradas por IA tendem a incluir, quando incluem, um campo de aceite genérico. Sem granularidade por finalidade. Sem registro de qual versão da política o usuário aceitou. Sem possibilidade de revogar o consentimento de forma granular. Em uma auditoria da ANPD, essa implementação não passa.
O direito de exclusão que o banco de dados não honra
A LGPD garante ao titular o direito de solicitar a exclusão de seus dados pessoais. Para honrar esse direito, o sistema precisa ser capaz de identificar todos os lugares onde os dados de um usuário específico estão armazenados e excluí-los de forma verificável.
Apps vibe-coded frequentemente armazenam dados em múltiplas tabelas sem uma estratégia clara de como excluir todos os registros de um usuário específico. A funcionalidade de "excluir conta" remove o usuário da tabela principal mas deixa rastros em tabelas de log, analytics, histórico de transações. Tecnicamente não conforme.
4. Como avaliar se um app vibe-coded é confiável para dados reais
O checklist mínimo antes de aceitar usuários reais
Antes de abrir cadastro para usuários que vão inserir dados pessoais em qualquer aplicação construída com vibe coding, o checklist mínimo inclui:
Revisão de RLS no Supabase (ou equivalente no banco de dados usado). Cada tabela que contém dados de usuário deve ter políticas que impedem acesso cruzado entre usuários. Teste manualmente: crie dois usuários, autentique como o primeiro e tente acessar os dados do segundo via API direta.
Auditoria de endpoints de API. Todos os endpoints que retornam dados devem verificar autenticação e autorização no servidor. Use uma ferramenta como Postman para fazer requisições diretas aos endpoints sem passar pelo frontend e confirme que retornam 401 ou 403 quando não autenticado.
Varredura automatizada de vulnerabilidades. Ferramentas como Snyk, Semgrep ou OWASP ZAP identificam vulnerabilidades comuns de forma automatizada. Uma varredura básica leva menos de uma hora e expõe os problemas mais óbvios.
Verificação de secrets no código e no histórico git. Use ferramentas como git-secrets ou truffleHog para varrer o repositório em busca de credenciais. Se encontrar, invalide as credenciais imediatamente e gere novas.
Teste de consentimento LGPD. Confirme que o fluxo de cadastro inclui consentimento explícito com link para política de privacidade, que o consentimento é registrado com timestamp e que existe mecanismo funcional de exclusão de dados.
Revisão de transferência de dados. Mapeie todos os serviços de terceiros usados pelo app (analytics, CDN, e-mail, pagamento) e confirme onde os dados de usuários são processados. Serviços fora do Brasil exigem cláusulas contratuais específicas para conformidade com LGPD.
Os testes que a maioria não faz
Além do checklist, existem testes específicos que revelam as vulnerabilidades mais comuns em apps vibe-coded:
• Teste de acesso cruzado: crie dois usuários de teste. Autentique como o usuário A. Tente acessar os recursos do usuário B pela URL direta (ex: /api/users/ID_DO_USUARIO_B/dados). Se o app retornar os dados, você tem IDOR.
• Teste de bypass de frontend: use o DevTools do browser para identificar as requisições de API que o frontend faz. Reproduza essas requisições sem autenticação usando Postman ou curl. Se receber dados, a autenticação é client-side.
• Teste de rate limiting: tente fazer 100 requisições em sequência rápida ao endpoint de login. Se todas forem aceitas sem bloqueio, rate limiting está ausente.
• Teste de injeção: em campos de busca e formulários, insira uma aspa simples (') e observe a resposta. Um erro de banco de dados na resposta indica SQL Injection.
Quando contratar um profissional de segurança
O checklist e os testes acima são suficientes para identificar os problemas mais óbvios. Mas não substituem uma análise de segurança profissional para aplicações com dados sensíveis ou volumes significativos de usuários.
Os critérios que indicam necessidade de análise profissional:
• O app processa dados de saúde, dados financeiros ou qualquer categoria sensível definida pelo Art. 11 da LGPD.
• O app vai ter mais de mil usuários no primeiro mês.
• O app integra com sistemas de pagamento ou tem transações financeiras.
• O app é B2B e seus clientes vão solicitar relatórios de segurança (SOC 2, pentest) como parte do processo comercial.
• Você está em um setor regulado: saúde, educação, financeiro, jurídico.
5. O que fazer quando o app já está em produção
A ordem de prioridade para correção
Se você tem um app vibe-coded já em produção com usuários reais e está lendo este artigo com preocupação crescente, a ação mais importante é não entrar em pânico e priorizar a correção pelo impacto potencial de cada vulnerabilidade.
A ordem de prioridade que recomendamos, com base nos dados disponíveis:
• Primeiro: RLS e controle de acesso a dados. É a vulnerabilidade com maior impacto potencial e a mais comum. Corrija antes de qualquer outra coisa.
• Segundo: secrets expostos. Se há credenciais no código ou no histórico git, invalide-as imediatamente. Gere novos tokens antes de corrigir o código.
• Terceiro: autenticação e autorização no servidor. Mova toda verificação de permissão para o backend. Nunca confie no frontend para controlar acesso a dados.
• Quarto: LGPD básica. Consentimento documentado e mecanismo de exclusão de dados. São requisitos legais que precisam estar presentes.
• Quinto: varredura automatizada. Rode Snyk ou OWASP ZAP e corrija o que for reportado como crítico ou alto.
A comunicação com usuários
Se durante a revisão você identificar que dados de usuários podem ter sido expostos, a LGPD exige notificação à ANPD em prazo razoável e, dependendo da gravidade, notificação aos próprios titulares. Esse não é um processo que você quer descobrir enquanto gerencia uma crise. Defina antes o protocolo de notificação.
A transparência proativa, quando há risco real de exposição, tende a resultar em consequências menos graves do que a descoberta posterior de que um vazamento ocorreu e não foi comunicado.
Nenhum usuário que confiou seus dados ao seu app vai perdoar uma negligência de segurança. Mas muitos vão respeitar uma empresa que agiu com transparência e velocidade quando identificou um problema.
6. Como a Tryvia aborda segurança em projetos de automação
O que aprendemos no caminho
A Tryvia constrói automações de vendas com IA para PMEs brasileiras. Nosso stack envolve WhatsApp Business API, N8N, Supabase e agentes de IA. Código que vai para produção e toca dados reais de leads, clientes e operações comerciais de nossos clientes.
No início da nossa adoção de ferramentas de geração de código por IA, cometemos parte dos erros que este artigo descreve. Não por descuido, mas por subestimar a diferença entre "funciona nos testes" e "é seguro para dados reais". A correção nos custou tempo e retrabalho que poderiam ter sido evitados com um processo mais robusto desde o início.
O processo atual
Hoje, qualquer código que toca dados de clientes em nossos sistemas passa por um processo que inclui:
• Revisão de RLS antes de qualquer deploy em ambiente de produção.
• Varredura automatizada com Snyk integrada ao pipeline de CI/CD.
• Auditoria manual de endpoints que retornam dados de usuários.
• Gestão de secrets via variáveis de ambiente, nunca em código ou em repositórios.
• Registro de consentimento para todos os fluxos que coletam dados pessoais de leads.
Não é um processo perfeito. É um processo que evoluiu com a prática e que continua evoluindo. O que garantimos é que nenhum dado de cliente vai para produção sem esses controles mínimos.
A velocidade tem um preço. Vale a pena conhecê-lo antes de pagar
Construir um app em três dias é genuinamente possível com as ferramentas disponíveis em 2026. O que não é possível é construir um app seguro e legalmente conforme em três dias sem um processo deliberado para garantir essas propriedades.
Segurança e conformidade não são funcionalidades que se adicionam no final. São propriedades arquiteturais que precisam estar presentes desde o início ou que custam significativamente mais para adicionar depois que o sistema está em produção com dados reais.
O vibe coding não é incompatível com segurança. É incompatível com a abordagem de não pensar em segurança. Times que usam vibe coding com processo adequado de revisão constroem apps funcionais e seguros. Times que usam vibe coding como atalho para pular processo constroem apps que funcionam e são vulneráveis.
O próximo e último artigo desta série é o mais específico: a Tryvia abre seu próprio stack técnico, mostra onde usa vibe coding, onde não usa e por quê. Transparência técnica como forma de demonstrar na prática o que os artigos anteriores descreveram em teoria.
SOBRE A TRYVIA
A Tryvia é especialista em automação de vendas com inteligência artificial para empresas brasileiras. Desenvolvemos soluções que integram WhatsApp Business API, agentes de IA e workflows N8N para aumentar conversão e escalar operações comerciais sem aumentar time de vendas.
