Seu login funciona. Isso não quer dizer que os dados dos seus clientes estão protegidos.

Vou te mostrar o teste primeiro, porque ele é curto e você pode rodar hoje. Depois explico por que ele importa mais do que qualquer outra coisa que você vai fazer no seu app essa semana.

O teste dos dois usuários

Você vai precisar de dois cadastros no seu próprio app e de dois navegadores diferentes — ou um normal e um em janela anônima.

Passo 1. Crie a conta A. Faça login. Crie alguma coisa que seja sua: um pedido, um cliente, uma nota, o que o seu app guarda.

Passo 2. Olhe o endereço na barra do navegador enquanto está vendo esse item. Muitas vezes ele termina com um identificador:

meuapp.com.br/pedido/1043

Anote esse número.

Passo 3. No outro navegador, crie a conta B. Faça login com ela. Confirme que a conta B não tem nada — lista vazia, tudo limpo.

Passo 4. Agora, logado como B, digite na barra de endereço o link do item da conta A:

meuapp.com.br/pedido/1043

Passo 5. Olhe o que aparece.

Se a tela disser que não existe, ou que você não tem permissão, ótimo. Se o pedido da conta A abrir na tela da conta B, você acabou de encontrar a falha mais comum em aplicação feita com IA.

E ela tem uma característica que faz dela a pior de todas: até você fazer esse teste, tudo parecia perfeito.

Por que o login não resolveu isso

Aqui vale traduzir duas palavras que quase sempre aparecem juntas e significam coisas diferentes. Se você levar só isso deste post, já valeu.

Autenticação é quem é você. É o login. O app conferiu e-mail e senha e sabe que você é você.

Autorização é o que você pode ver. É outra pergunta, feita depois, item por item: essa pessoa específica pode ver esse dado específico?

Quando você pede um app pra IA, ela quase sempre implementa a primeira com capricho — login, senha, recuperação, tudo bonitinho. A segunda ela costuma deixar pela metade, porque no caminho feliz do teste ela nunca aparece: quando só existe um usuário, todo dado é dele mesmo.

Aí você publica. Chega o segundo cliente. E o app, que nunca foi ensinado a perguntar "esse dado é seu?", entrega.

Essa falha tem nome técnico — os relatórios chamam de IDOR, ou falha de autorização por referência direta. Você não precisa decorar a sigla. Precisa lembrar da frase: trocar o número no endereço e ver o dado de outra pessoa.

A segunda versão do mesmo teste

Tem uma variação que pega mais gente ainda, e vale rodar junto.

Se o seu app tem qualquer coisa de administrador — painel, relatório, lista de todos os clientes, botão de exportar —, faça o seguinte: logado com uma conta comum, digite direto o endereço da área de admin.

meuapp.com.br/admin

Muita aplicação gerada por IA esconde o botão do admin de quem não é admin, e considera o trabalho feito. Esconder o botão não protege o endereço. Quem digitar entra.

A regra, em uma frase que você pode repetir pra IA: checar permissão na tela não vale; a checagem tem que acontecer no servidor, antes de o dado sair.

Terceiro teste: a chave que ficou no lugar errado

Esse é ainda mais rápido e não precisa de segunda conta.

Abra seu app publicado, clique com o botão direito, escolha "Exibir código-fonte da página" e use a busca (Ctrl+F ou Cmd+F). Procure por:

secret
service_role
api_key
sk_live

Se aparecer alguma chave de verdade ali, ela está pública. Qualquer visitante do seu site pode lê-la — não é preciso invadir nada, é só olhar.

Existem dois tipos de chave nesses serviços: uma pública, feita pra ficar no navegador, e uma secreta, que dá acesso total ao banco e só pode existir no servidor. A IA às vezes usa a secreta porque assim funciona de primeira e ela não precisa lidar com permissão nenhuma. Funciona lindamente. E deixa a porta escancarada.

Se você achou uma, o procedimento é: gerar uma chave nova no painel do serviço (isso invalida a antiga), guardar a nova como variável de ambiente no servidor, e nunca colar a secreta em nada que vá pro navegador.

"Mas quem ia se dar ao trabalho de mexer no meu app?"

Essa é a objeção que eu mais ouço, e ela parte de uma imagem errada do que acontece.

Ninguém escolheu você. Não tem uma pessoa sentada decidindo atacar o seu negócio. O que existe são programas automáticos varrendo a internet inteira, o dia todo, procurando endereço que responde e chave que ficou exposta. Eles não sabem se o seu app tem três usuários ou trinta mil. Eles sabem que a porta abriu.

Sobre o tamanho disso, alguns números medidos por gente que fez a conta:

• Em outubro de 2025, a empresa Escape varreu mais de 5.600 aplicações feitas com IA e publicamente acessíveis. Encontrou mais de 2.000 vulnerabilidades, mais de 400 chaves de acesso expostas e 175 casos de dado pessoal à mostra — incluindo informação financeira e médica.
• Em 2026, um estudo acadêmico montou um corpus de 10.517 aplicações feitas com IA, analisou 200 já publicadas e validou 1.471 vulnerabilidades, com falha de autorização e chave exposta entre os padrões que mais se repetiam.
• A Veracode mediu o código gerado por mais de cem modelos em 2025 e de novo em março de 2026: nas duas vezes, cerca de 45% das tarefas introduziam uma falha de segurança conhecida — mesmo com o acerto sintático passando de 95% na segunda medição.

O que esses números dizem juntos não é "IA é ruim". É:

A IA ficou excelente em produzir código que roda. Não melhorou na mesma proporção em produzir código que protege.

E como falha de proteção não dá sintoma, ela só aparece quando alguém procura. Você procurando hoje é infinitamente melhor do que a alternativa.

E a LGPD?

Rápido e sem drama, porque isso costuma ser tratado ou como pânico ou como se não existisse.

Se o seu app guarda nome, e-mail, telefone, CPF, endereço ou qualquer dado de cliente, você é responsável por esse dado perante a LGPD. Não importa que a plataforma tenha gerado o código, nem que você não saiba programar. A responsabilidade é de quem decide o que é feito com o dado — ou seja, sua.

Isso não quer dizer que você precisa de um jurídico antes de publicar. Quer dizer que "eu não sabia" não é defesa, e que os três testes acima são o mínimo antes de convidar o primeiro cliente de verdade.

O que fazer com o que você encontrar

Se algum dos três testes acusou problema, o pedido pra IA precisa ser específico. "Melhore a segurança" não funciona — é vago demais, ela vai fazer qualquer coisa e dizer que resolveu.

Peça assim, um de cada vez:

"No servidor, antes de devolver o pedido, confira se ele pertence ao usuário que está logado. Se não pertencer, responda com erro de permissão, e não com o dado."

"Proteja a rota de admin no servidor, checando o papel do usuário. Esconder o botão na tela não basta."

"Tire a chave secreta do lado do navegador. Ela deve existir só como variável de ambiente no servidor."

E — isso é o mais importante — depois de cada correção, rode o teste dos dois usuários de novo você mesmo. Não aceite "pronto, corrigido" como resposta.

A IA dizer que consertou não é evidência de que consertou. Isso vale tanto que é o assunto do próximo post.