Construtores de apps com IA publicaram milhares de aplicativos que vazam dados

Plataformas como Lovable, Base44, Replit e Netlify usam IA para permitir que qualquer pessoa, mesmo sem conhecimento de programação, crie aplicativos web completos em poucos segundos. Mas pesquisadores da Wired encontraram uma rachadura nessa utopia: milhares de aplicativos com dados confidenciais críticos, como chaves de API, senhas e tokens de autorização, estão expostos na internet. E ninguém faz nada a respeito.

Como funcionam os construtores de apps com IA

Serviços como Lovable e Base44 são baseados em grandes modelos de linguagem, como o GPT-4. O desenvolvedor apenas descreve o que precisa: "Faça um aplicativo para controlar despesas com integração ao Stripe". Em poucos segundos, o sistema gera um componente React ou um aplicativo Vue completo, com front-end e lógica. Depois, o projeto pode ser publicado na hora pelo Netlify, com um só botão, ou hospedado no Replit.

Isso é revolucionário para a velocidade de desenvolvimento. Um MVP normalmente exige semanas ou meses de trabalho. Aqui, leva horas, às vezes minutos. Não surpreende que centenas de milhares de desenvolvedores tenham começado a usar esses serviços.

A escala do problema

A Wired decidiu verificar o que vai parar em acesso público. Os pesquisadores analisaram milhares de aplicativos criados nessas plataformas e publicados na internet aberta. O resultado foi alarmante: uma parcela significativa continha chaves de API, senhas de bancos de dados e outros dados confidenciais.

Não são casos isolados de descuido. É um problema sistêmico: as plataformas não têm mecanismos para evitar vazamentos. Quando o código é gerado automaticamente e publicado com um só botão, o processo de revisão de segurança simplesmente desaparece.

Quais dados estão vazando

• Chaves de API de serviços de terceiros — OpenAI, Stripe, AWS, Google Cloud, Twilio. Todas ficam em código JavaScript do lado do cliente, que qualquer pessoa pode baixar.
• Senhas de bancos de dados — as credenciais de MongoDB, PostgreSQL e MySQL muitas vezes não têm hash e aparecem em texto puro no código-fonte do aplicativo.
• Tokens de autorização e cookies de sessão — que permitem sequestrar contas alheias.
• Chaves criptográficas privadas — usadas para proteger os dados dos usuários.
• IDs internos e arquitetura — mesmo que sejam seguros isoladamente, juntos revelam a estrutura do aplicativo para atacantes.

Quando os pesquisadores encontraram essas chaves, conseguiram acessar contas e dados de usuários. Além disso, bots que varrem a internet o tempo todo atrás desses vazamentos já os encontram de forma automática.

Por que isso acontece

O motivo principal é simples: a velocidade de desenvolvimento não deixa tempo para a segurança. Quando dá para criar um MVP em 10 minutos, não há revisão de código, verificação de vulnerabilidades nem processo padrão. Em projetos grandes, isso seria detectado.

O segundo motivo é que as próprias plataformas não fazem nada. Elas não avisam o desenvolvedor de que uma chave de API foi encontrada no código. Não há remoção automática de dados sensíveis. Não há um aviso como "Certifique-se de ter removido todas as senhas antes de publicar". É só publicar, e pronto.

O terceiro motivo é que os desenvolvedores não têm treinamento. Alguém que ontem não sabia programar hoje cria um aplicativo com lógica real. Ninguém explicou a essa pessoa as regras básicas de segurança.

O que isso significa

É um caso clássico de democratização que não saiu totalmente como deveria. As ferramentas de fato permitem que mais gente crie. Mas a margem para erros também aumenta.

Para as empresas: se usam essas plataformas em aplicativos de produção, apenas gerar o código não basta. É indispensável verificá-lo manualmente em busca de vazamentos antes de publicar. Procurem chaves de API no código-fonte, senhas nos arquivos de configuração e dados privados nos logs.

Para as próprias plataformas, este é um momento crítico. Elas precisam de verificações de segurança integradas, alertas ao detectar chaves e, talvez, até a recusa de publicar. Caso contrário, a reputação delas vai sofrer.