As 5 vulnerabilidades que seu app criado com IA provavelmente tem (e como encontrar cada uma)
Seu app feito com IA funciona, tá bonito, até pegando clientes — mas a IA não te avisou que deixou portas abertas. Inspirado no vídeo do Mano Devin, este guia lista as 5 falhas mais comuns em apps criados com Vibe Coding e mostra ferramentas gratuitas para encontrar e fechar cada brecha.
Subir um SaaS com Vibe Coding é quase um rito de passagem para devs indie hoje em dia. Ferramentas como Cursor, Claude Code, Lovable e Bolt entregam um app funcionando em horas. Mas o que a IA não te conta é que ela pode estar deixando várias portas abertas no caminho.
O canal Mano Devin, referência em segurança para devs brasileiros, publicou um vídeo imperdível analisando as cinco vacilações mais comuns em apps criados com IA — e pior: elas estão em apps sérios, de gente grande, não só em projetos de fim de semana.
O problema não é a IA. O problema é que ela otimiza para "funcionar", não para "resistir a ataque".
Abaixo, as 5 vulnerabilidades, explicadas com exemplos reais, e como você mesmo pode encontrar cada uma — de graça.
1. RLS desligado — o cofre sem porta
Se você usa Supabase ou Firebase, seu banco de dados fala direto com o navegador. Não tem um servidor backend protegendo a transação de dados. A proteção nesse modelo se chama RLS (Row Level Security): uma trava que garante que cada usuário só vê os dados dele.
O problema? O RLS vem desligado por padrão. É como comprar um cofre imponente, colocar no escritório, mas deixar a porta destrancada.
Dado real: 83% dos vazamentos do Supabase estão relacionados a RLS mal configurado ou desativado, segundo estudo de 2025. Uma CVE do ano passado expôs dados de mais de 170 aplicações de uma vez.
E o pior: o Yuri Dev mostrou um caso onde o cara simplesmente pediu o banco de dados da aplicação — e o banco entregou. Nome de revendedores, WhatsApp, lojas. Sem senha, sem invasão. Só pediu.
Como encontrar: Acesse o painel do Supabase, vá em SQL Editor e rode SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public';. Tabelas com rowsecurity = false estão destravadas.
Como resolver: Ative o RLS em cada tabela e crie políticas de acesso. Uma linha de SQL resolve.
2. Permissão de admin no frontend — o localStorage que decide quem manda
Essa é clássica e assustadoramente comum. O app define se o usuário é administrador ou não direto no frontend, geralmente no localStorage do navegador.
O Yuri Dev demonstrou: abriu o Inspecionar Elemento, mudou admin: false para admin: true no localStorage, deu F5 e entrou no painel administrativo. O caso mais famoso foi o do influenciador Riter (22 milhões de seguidores), onde uma única palavra trocada no localStorage liberou aulas inteiras que nem tinham sido lançadas.
Regra de ouro: regra de negócio vive no backend, não no frontend. O frontend só renderiza. Se você deixa o navegador decidir quem é admin, o navegador vira o melhor amigo do hacker.
Como encontrar: Abra o DevTools do seu navegador (F12), vá em Application > Local Storage e procure por campos como admin, role, isAdmin, userType. Se estão no frontend e o backend confia cegamente neles, você tem uma falha.
Como resolver: Toda verificação de permissão deve ser validada no servidor. O frontend pode exibir ou esconder botões, mas o backend é quem decide se a requisição é autorizada.
3. IDOR — o balcão da farmácia que entrega dado de todo mundo
IDOR (Insecure Direct Object Reference) é uma das falhas mais fáceis de explorar e mais ignoradas pelo Vibe Coding. A lógica é simples:
Imagine um balcão de farmácia. Você chega e fala "pedido 105". O atendente entrega. Você fala "pedido 106". Entrega também. 107, 108... Em 5 minutos você levou os pedidos da rua inteira.
É exatamente isso que acontece quando uma rota tipo /api/user/3 devolve os dados do usuário 3 sem verificar se você é o usuário 3. O atacante troca o número na URL e pega os dados do vizinho: telefone, saldo, e-mail.
Como a IA contribui: Quando você pede "cria um CRUD de usuários" ou "rota de busca de pedido pelo ID", a IA gera exatamente isso — um endpoint que busca pelo ID, sem verificar se o ID pertence à pessoa logada. Se você não pedir essa verificação, ela não vem.
Essa é a #1 da lista OWASP de falhas de API.
Como encontrar: Use o OWASP ZAP (ferramenta gratuita). Dê o endereço do seu app, ela sai batendo em todas as rotas e testando variações de ID.
Como resolver: Sempre confira se o recurso solicitado pertence ao usuário autenticado. Nunca confie no ID que o cliente enviou sem validar propriedade.
4. Chaves de API hard-coded — o segredo que virou público
Esse é o vacilo que entrega a senha do seu aplicativo para qualquer um que abrir o Inspecionar Elemento.
Toda integração (gateway de pagamento, e-mail, armazenamento em nuvem) fornece uma chave de API. Essa chave deve ficar no servidor, em variável de ambiente. Mas a IA, se você der mole, simplesmente joga ela hard-coded no código.
E o pior: quando você faz o build do frontend, toda variável vira JavaScript público. Qualquer um pode ler abrindo o DevTools.
Só em 2024, 24 milhões de segredos vazaram dessa forma, segundo levantamento de segurança. Bots varrem o GitHub em tempo real atrás de chaves expostas.
O Yuri Dev mostrou o caso de um golpista que achou a chave do gateway de pagamento dentro de um arquivo público no GitHub. Nas palavras dele: "o golpista nunca ouviu falar de .gitignore".
Como encontrar: Use Gitleaks (gitleaks detect --source .) para varrer seu repositório em busca de chaves, senhas e tokens vazados no histórico do Git. Mesmo que você tenha apagado depois, o histórico guarda.
Como resolver: Chaves de API nunca vão no frontend. Use variáveis de ambiente (process.env.API_KEY) no servidor, e endpoints proxy no backend para qualquer serviço externo.
5. XSS — a feature que era uma falha
Essa é a mais traiçoeira porque não tem cara de falha — tem cara de feature.
O caso do Riter: o curso tinha um campo de "HTML personalizado" no painel, que permitia escrever código que rodava em todas as páginas. E no upload de perfil, aceitava qualquer arquivo. Mandaram uma imagem com um script escondido dentro e roubaram a sessão do admin.
Isso se chama XSS (Cross-Site Scripting). O usuário digita um código ao invés de texto, e o site executa aquele código achando que era conteúdo legítimo.
45% do código gerado por IA tem falha desse tipo, segundo a Veracode. Quase metade.
A regra é simples: num sistema seguro, tudo que o usuário digita é mentira até que se prove o contrário. Trate input como hostil.
Como encontrar: Use OWASP ZAP (que tem scanner de XSS automático) ou TruffleHog (fork open source do projeto Srap). Ambos são gratuitos.
Como resolver: Valide, sanitize e limite todo input do usuário. Nunca confie que o conteúdo é seguro só porque veio de um campo de texto.
Como o ecoa.dev te ajuda a fechar essas brechas
O ecoa.dev foi feito exatamente para preencher essa lacuna entre "app funcionando" e "app seguro".
O Scan Service do ecoa.dev faz uma varredura completa em minutos:
- Descobre endpoints sensíveis expostos (
.env,.git, painéis administrativos) - Verifica headers de segurança (HSTS, CSP, cookies seguros)
- Testa redirecionamento HTTPS forçado, SSL/TLS
- Detecta vulnerabilidades como SSRF e injeção
Além disso, o LGPD Analyzer verifica se seu app está em conformidade com a lei brasileira — política de privacidade, cookies, canal do titular. O tipo de checklist que nenhuma ferramenta de Vibe Coding gera por conta própria.
E quando o scan encontra uma falha, o ecoa gera um prompt de correção pronto para você colar de volta na sua ferramenta de IA favorita. Você não precisa entender de segurança profunda: é copiar, colar no Cursor ou Claude, e a IA ajusta o código.
Teste seu app em ecoa.dev antes que alguém teste por você.