Todo app tem duas plateias. A primeira usa o produto do jeito que você imaginou, clica onde tem botão e preenche o que o formulário pede. A segunda abre o painel de rede do navegador, troca um número na requisição e vê o que volta. O seu app foi testado pela primeira plateia todos os dias desde que existe. A segunda chega sem avisar.
Isso não é uma crítica a quem construiu com IA. É a descrição do que a pesquisa pública vem medindo, e o padrão é consistente o bastante para virar checklist.
O que uma varredura de apps publicados encontrou
A empresa de segurança Escape publicou em outubro de 2025 a metodologia de uma varredura em cerca de 5.600 aplicações públicas construídas em plataformas de geração de app, entre elas Lovable, Base44, Create.xyz, Vibe Studio e Bolt. O levantamento encontrou mais de 2.000 vulnerabilidades, mais de 400 segredos expostos e 175 casos de dado pessoal alcançável, incluindo registro médico e dado financeiro. Entre os achados mais comuns estão tokens anônimos expostos dentro do pacote JavaScript que o navegador baixa, apontando direto para a API do banco, e regras de acesso por linha mal configuradas entre a camada de API e o banco. A metodologia está publicada.
Vale ler o que essa lista tem em comum. Nenhum desses achados exige invadir nada. Todos aparecem para quem simplesmente abre o site e olha o que o próprio navegador já recebeu. É por isso que a comparação com arrombamento não ajuda: a porta não foi forçada, ela estava anotada no vidro.
E o rastro já chega nos registros oficiais de vulnerabilidade
Em abril de 2026, a Georgia Tech divulgou o Vibe Security Radar, projeto do Systems Software and Security Lab da escola de cibersegurança e privacidade, liderado pelo pesquisador Hanqing Zhao. A ferramenta varre bases públicas de vulnerabilidade e procura assinaturas de ferramentas de IA no código que originou a falha, rastreando metadados como marcações de coautoria e endereços de bot. O grupo varreu mais de 43 mil avisos de segurança e encontrou 18 casos nos sete meses finais de 2025 contra 56 casos apenas no primeiro trimestre de 2026, sendo 35 deles em março. Dos 74 casos confirmados, 14 são críticos e 25 de alto risco. A Georgia Tech publicou o resumo da pesquisa.
A leitura útil não é a contagem, é a curva. O que era anedota de fórum em 2025 já está entrando em base pública de vulnerabilidade em 2026, o que significa que a classe de falha deixou de depender de alguém contar a história. Ela agora é rastreável por terceiros, inclusive pelo time de segurança do cliente que está avaliando você.
O motivo é mais chato do que “a IA escreve código ruim”
A pesquisa do Stack Overflow de 2025, com cerca de 49 mil respondentes, mostra 84% usando ou pretendendo usar IA no desenvolvimento, 33% confiando na precisão, 46% desconfiando ativamente, 66% apontando como maior frustração as respostas “quase certas, mas não exatamente”, e 45% dizendo que depurar código gerado consome mais tempo. Os dados estão abertos.
“Quase certo” descreve com precisão o tipo de falha que aparece nesses apps. Uma checagem de permissão que existe, mas mora na interface em vez do banco. Uma política de acesso por linha ligada, mas sem regra escrita para a escrita. Uma chave que funciona, e funciona demais. Nada disso quebra a tela, e é justamente por isso que nada disso aparece nos seus testes de uso.
O estudo The Maintainability Gap, da GitClear com a GitKraken, sobre 623 milhões de mudanças de código entre 2023 e 2026, mostra o outro lado do mesmo fenômeno: duplicação de blocos em alta de 81%, copy e cola no mesmo commit em alta de 41%, refatoração caindo de 21% das linhas alteradas em 2022 para 3,8% em 2026. O estudo está publicado. Código duplicado é o que faz uma correção de segurança precisar ser aplicada sete vezes, e é o que explica por que o segundo conserto costuma custar mais que o primeiro.
As quatro perguntas do teste do estranho
Estas são as perguntas que a segunda plateia responde por você se você não responder antes. Todas são conferíveis no seu próprio ambiente, e nenhuma exige ferramenta cara:
- Um usuário de uma empresa alcança o registro de outra trocando um id na requisição? Testar em homologação, com dado semeado, na leitura e na escrita. Política de acesso por linha ligada não é a mesma coisa que política escrita e cobrindo escrita.
- Alguma chave que ignora essas políticas está rodando no navegador, ou numa função sem verificação de token? É o achado mais comum das varreduras públicas e o mais barato de consertar.
- O que acontece com quarenta pessoas ao mesmo tempo? Não estimado: medido. E o truque de diagnóstico mais útil é fazer carga contra o endpoint que não faz nada. Se até ele degrada, o problema não é o banco.
- Se um dado vazar hoje, você consegue dizer quantas pessoas foram alcançadas? Essa resposta não vem da política de privacidade, vem da trilha de auditoria de acesso.
O que a gente aprendeu fazendo isso no próprio produto
A gente roda um SaaS de compliance em produção, construído como a maioria desses é construída: rápido, com muito código gerado, sob prazo. Quando fomos medir, com 25 usuários simultâneos apenas 11% das requisições tinham sucesso. Não era lentidão, era falha. A causa não era o banco: eram 22 pontos de código travando o event loop, com OCR, rasterização de PDF e leitura de upload rodando de forma síncrona dentro de rotas assíncronas. Depois do conserto, 26 usuários simultâneos com 100% de sucesso, 874 requisições e nenhum timeout, com mediana de 297 ms.
No mesmo produto, o isolamento entre inquilinos está ativo em 167 tabelas do banco, conferido tabela a tabela depois de uma migração completa de nuvem, e cada deploy passa por uma suíte de mais de 1.500 testes automatizados. Escrevemos o caminho inteiro desse diagnóstico em outro artigo aqui do blog, com o método de medição, porque o passo a passo é reproduzível por qualquer um no próprio sistema.
A parte que interessa não é o número. É que antes de medir a gente também achava que estava bem, e a plateia que teria descoberto por nós seria um cliente numa segunda de manhã.
O que fazer com isso hoje
- Abrir o pacote que o navegador baixa e procurar por chave e token. É a checagem de dez minutos com maior retorno que existe.
- Criar duas empresas de teste em homologação e tentar, de propósito, alcançar o dado de uma pela sessão da outra.
- Rodar uma carga simples e observar o endpoint mais bobo do sistema.
- Escrever, em uma página, quais dados pessoais o sistema guarda, por quanto tempo e quem consegue ler.
Os quatro juntos custam uma tarde. Nenhum deles precisa de fornecedor, de contrato ou de permissão de ninguém, porque acontecem dentro da sua própria casa.
Leitura recomendada
- Escape, metodologia da varredura em cerca de 5.600 apps publicados: escape.tech
- Georgia Tech, Vibe Security Radar e a curva de CVEs ligados a ferramentas de IA: news.research.gatech.edu
- Stack Overflow Developer Survey 2025, seção de IA: survey.stackoverflow.co
- GitClear e GitKraken, The Maintainability Gap: gitclear.com
Se quiser ir além do checklist
Quando essas perguntas chegam pelo jurídico de um cliente, elas vêm com prazo e por escrito. A página fabership.com.br/lgpd explica o que a gente faz nesse caso e o que não faz, e a porta de entrada continua sendo o autodiagnóstico que você mesmo roda. A gente não toca em sistema nenhum sem contrato assinado e autorização por escrito, inclusive para demonstrar valor.