Segurança
Os 3 lugares por onde dado sensível vaza num app feito com IA
Não é hacker. Na prática, quase todo vazamento em app feito com IA vem de três lugares chatos e previsíveis. Os três dão pra conferir hoje, sem ser programador.
Vazamento de dado quase nunca é filme.
Não tem invasor genial, não tem madrugada tensa. Tem uma configuração que ficou aberta e ninguém olhou.
Em app feito com IA, três lugares concentram a maioria dos casos. Os três dão pra conferir hoje.
1. A regra do banco que ficou aberta
É o campeão absoluto.
Você pede um sistema, a IA monta o banco, e pra tudo funcionar de primeira ela deixa a permissão liberada. Alguma variação de "qualquer um pode ler e escrever".
E funciona. Funciona lindamente. O sistema roda, o cliente aprova, você sobe.
Só que a regra continua lá. Qualquer pessoa com o endereço do seu banco lê a base inteira, do navegador, sem invadir nada. Não é ataque, é a porta aberta com plaquinha.
Como conferir: abra o painel do banco e leia a regra. Se tiver permissão de leitura pra todo mundo sem condição, você achou.
O que fazer: ninguém lê nada por padrão, e você abre exceção só onde precisa, sempre amarrada ao usuário dono do dado. Escrevi o passo a passo em conectar banco de dados sem medo.
2. O segredo que foi parar no código
Chave de API, token, senha de serviço. A IA coloca no arquivo pra funcionar, você nem repara, e aquilo sobe.
Dois destinos, e os dois são ruins. Se foi pro código que roda no navegador, qualquer visitante lê. Se foi pro repositório, ficou registrado na história do Git mesmo depois de você apagar.
O caso mais caro é chave que gasta dinheiro. Chave de IA achada é conta de terceiro rodando na sua fatura, e você descobre pelo valor.
Como conferir: procure no projeto por trechos como sk-, api_key, secret e password. Depois confira se existe arquivo de ambiente versionado por engano.
O que fazer: segredo vai em variável de ambiente, no servidor, e o arquivo de ambiente entra no gitignore. Se já foi pro Git, considera vazado e gera outro, porque apagar não desfaz. Detalhei em nunca vaze uma senha.
3. O endereço que não confere de quem é o dado
Esse é o mais silencioso.
Sua tela de pedido chama algo como barra pedido barra 1024. Você troca pra 1025 e aparece o pedido de outra pessoa.
Aconteceu porque a checagem de permissão ficou na tela, não no servidor. A tela esconde o botão, e quem não usa a tela pega o dado direto.
E é justamente o tipo de coisa que a IA não cobre sozinha: você pediu "mostre o pedido do usuário" e ela entregou uma função que mostra o pedido. Você não pediu "recuse se o pedido for de outro", então ela não recusou.
Como conferir: entre com uma conta, abra uma tela que mostre algo seu, troque o número no endereço e veja se aparece dado de outro. Leva um minuto.
O que fazer: a pergunta "esse dado é dessa pessoa" mora no servidor, sempre, em toda rota que devolve dado de alguém.
O que os três têm em comum
Nos três, o errado funciona igualzinho ao certo.
É por isso que passam batido. Bug normal aparece: a tela quebra, o botão não responde, alguém reclama. Falha de segurança não aparece. O sistema roda perfeito até o dia em que alguém repara.
Por isso não dá pra confiar em "testei e funcionou". Funcionar é o mínimo, não é a prova.
Reserva vinte minutos hoje e confere os três no seu projeto. Se achar algum, você acabou de evitar a semana mais cara do seu ano.
A decisão é sua.
Perguntas frequentes
Perguntas rápidas
+Por que a IA gera código com esses problemas?
Porque ela otimiza pra funcionar, e nesses três pontos o inseguro funciona igual ao seguro. Regra aberta funciona. Segredo no código funciona. Endereço sem checagem funciona. A diferença só aparece quando alguém tenta abusar, e ninguém testa isso por padrão.
+Como sei se minha regra de banco está aberta?
Abra o painel do seu banco e leia as regras. Se houver algo equivalente a permitir leitura para todos, sem condição de usuário, está aberta. No Firestore, a frase clássica é a que libera leitura e escrita sem checar quem está pedindo.
+Chave de API no código é sempre problema?
Chave que roda no navegador é pública por definição, então nunca coloque ali uma que dê poder de escrita ou de gasto. Chave de servidor vai em variável de ambiente e nunca no repositório. Se já foi para o Git, considere vazada e gere outra.
+Dá pra conferir isso sem ser programador?
Os três, sim. Ler a regra do banco, procurar chave no código e abrir a tela de outro usuário trocando o número no endereço. Nenhum dos três exige escrever código, só exige olhar.
Continue lendo
Como separar dado real de dado de teste (o que a LGPD cobra)
Testar com a base de produção é o atalho mais comum e o mais caro. Separar ambiente é mais simples do que parece, e a LGPD não trata isso como detalhe.
SegurançaO risco não é o código que você escreve. É o que você instala
Hackers injetaram malware no open source da Microsoft. A lição pra quem constrói com IA: seu maior risco não é o código que você escreve: é o que você instala.
SegurançaVocê soltou um agente de IA sem revisar o que ele pode
88% das empresas já tiveram incidente com agente de IA, mas só 14% subiram com aval de segurança. O que esse abismo ensina pra quem constrói com IA.