Código Feito Por IA Tem Falha de Segurança? Como Checar

Por que a IA erra sempre nos mesmos lugares

A IA de programação aprendeu com uma quantidade enorme de código público. Boa parte desse código foi escrita para tutorial, para demonstração, para "rodar rápido no meu computador". Código de tutorial quase nunca tem segurança de verdade, porque segurança atrapalha o exemplo. Resultado: o modelo aprendeu que o jeito normal de escrever é o jeito simples, não o jeito protegido.

Some a isso o segundo fator: você pediu o que queria ver funcionando. Pediu tela de login, cadastro de cliente, área do administrador. Não pediu proteção contra invasão, porque proteção não é uma tela. A IA entrega o que foi pedido e não avisa o que faltou. Ela não é desonesta, ela é literal.

O terceiro fator é o mais perigoso: erro de segurança não dá erro. Se faltar um ponto e vírgula, a tela quebra e você percebe na hora. Se faltar verificação de login em uma página, tudo continua abrindo normalmente, só que abre para qualquer pessoa. Você só descobre quando alguém já entrou.

As cinco falhas que mais aparecem

1. Chave de acesso escrita dentro do código

Chave de acesso (ou API key) é a senha que seu sistema usa para falar com outros serviços: gateway de pagamento, envio de e-mail, serviço de IA, armazenamento de arquivos. A IA costuma colar essa chave direto no meio do arquivo, porque assim funciona de primeira.

O problema é duplo. Primeiro: se o código foi para um repositório público, a chave está visível para o mundo, e existem robôs que varrem repositórios públicos justamente atrás disso. Segundo: dependendo de onde a chave foi colocada, ela é enviada para o navegador do visitante, o que significa que qualquer pessoa pode vê-la com um clique em "inspecionar".

Uma chave de serviço de IA ou de nuvem vazada não é só constrangimento, é conta. Existem relatos frequentes de faturas que estouraram porque terceiros passaram a usar a chave alheia. O valor varia muito, mas a lógica é sempre a mesma: quem tem a chave gasta no seu nome.

2. Consulta ao banco de dados montada por texto

Aqui vale explicar o jargão. Toda vez que seu sistema busca algo no banco de dados, ele escreve uma pergunta interna do tipo "me traga o cliente cujo e-mail é tal". Se o sistema monta essa pergunta simplesmente colando o que o visitante digitou no formulário, o visitante pode digitar algo que não é um e-mail, e sim um comando. Isso se chama SQL injection, e é uma das falhas mais antigas e mais exploradas que existem.

O jeito correto é usar consulta com parâmetro: o sistema separa a pergunta do dado, e o banco trata o que veio do formulário sempre como texto, nunca como comando. As IAs modernas acertam isso com boa frequência, mas escorregam quando o pedido envolve busca com muitos filtros, ordenação dinâmica ou relatório configurável. É justamente nas telas mais complexas que o erro aparece.

3. Endereço de dados sem exigir login

Endpoint é o endereço interno que seu sistema chama para buscar ou salvar dados. Sua tela de "lista de clientes" é bonita e exige login. Mas o endereço que alimenta essa tela com os dados, algo como /api/clientes, muitas vezes fica desprotegido: qualquer pessoa que descobrir esse endereço recebe a lista inteira sem nunca passar pela tela de login.

Esse é, de longe, o furo mais comum em sistema gerado por IA. A IA protegeu a tela porque você viu a tela. Ninguém pensou no endereço por trás dela.

4. Verificação que só existe no navegador

Muita validação que a IA escreve acontece no navegador do usuário: campo obrigatório, valor mínimo, formato de CPF, perfil de administrador. Tudo isso pode ser burlado, porque o navegador é o computador do outro, e ali quem manda é ele. Se a mesma verificação não existir também no servidor, ela não vale nada. O caso clássico é o preço: se o valor do pedido chega ao servidor vindo do navegador em vez de ser recalculado, alguém pode comprar por um real.

5. Upload de arquivo sem filtro

Sistema que aceita foto de perfil, comprovante ou anexo precisa checar o tipo real do arquivo, limitar o tamanho e guardar em uma pasta que não execute nada. A IA costuma entregar o upload funcionando e sem nenhuma dessas três travas. É um caminho conhecido para alguém enviar um arquivo que roda dentro do seu servidor.

Roteiro de verificação antes de publicar

Você não precisa saber programar para rodar boa parte desta checagem. Precisa de paciência e de acesso ao projeto.

Um truque que funciona: peça a auditoria à própria IA

Abra o projeto na mesma ferramenta que gerou o código e peça algo assim: "revise este projeto procurando credenciais expostas, rotas sem autenticação, consultas ao banco sem parâmetro e validação que só existe no navegador. Liste arquivo, linha e como corrigir."

A IA é claramente melhor auditando do que se lembrando de proteger sozinha na hora de criar. Duas ressalvas honestas, porém. Ela aponta falhas que não existem, o chamado falso positivo, e em projeto grande devolve uma lista longa demais para tratar de uma vez. E ela tende a não enxergar problemas de lógica de permissão, do tipo "o usuário A consegue ver o pedido do usuário B trocando o número na URL". Esse tipo de falha depende de entender o seu negócio, não o seu código.

O que a IA não vai pegar sozinha

Vale ser realista sobre o limite da ferramenta. Alguns pontos praticamente nunca aparecem em revisão automática:

• Permissão entre usuários do mesmo nível. Trocar o número na URL e enxergar o dado de outro cliente é falha comum e totalmente silenciosa.
• Ausência de limite de tentativas. Tela de login sem bloqueio permite que um robô teste milhares de senhas sem nenhum obstáculo.
• LGPD e retenção de dados. Guardar CPF, endereço e histórico sem base legal e sem prazo de descarte é risco jurídico, não técnico.
• Registro com dado sensível. Sistema que grava senha ou número de cartão no log de erros cria um vazamento novo dentro de casa.
• Ambiente de produção mal configurado. Mensagem de erro detalhada exibida ao visitante entrega o mapa do sistema de graça.

Ordem de correção quando aparece muita coisa

Se a checagem apontou vários problemas, não tente resolver tudo ao mesmo tempo. A ordem que costuma fazer mais sentido é esta.

Primeiro, o que já vazou. Chave exposta se resolve trocando a chave no serviço de origem, não apagando do código. Apagar do arquivo não apaga do histórico. Gere credencial nova, revogue a antiga e só depois arrume o código.

Segundo, as portas abertas. Todo endereço que devolve dado precisa exigir login e checar se aquele usuário específico pode ver aquele dado específico. Não basta "está logado".

Terceiro, a entrada de dados. Consultas com parâmetro, validação no servidor, filtro de upload.

Quarto, o entorno. Backup testado, HTTPS ativo, dependências atualizadas, mensagens de erro genéricas para o visitante e detalhadas apenas no registro interno.

Se o sistema já movimenta dinheiro, guarda dado de cliente ou é a operação principal do negócio, uma revisão feita por alguém experiente compensa. O custo de uma auditoria varia bastante conforme o tamanho do projeto, mas costuma ser bem menor do que o custo de reconstruir a confiança do cliente depois de um vazamento.

Como pedir melhor desde o começo

Prevenir sai mais barato que corrigir. Quando for pedir uma funcionalidade nova para a IA, inclua as exigências de segurança dentro do próprio pedido. Algo como: "crie o cadastro de pedidos com consultas parametrizadas, validação no servidor, autenticação obrigatória na rota, verificação de que o pedido pertence ao usuário logado, e sem credenciais escritas no código, usando variáveis de ambiente".

É mais texto, e o resultado muda bastante. Vale também manter no projeto um arquivo de instruções permanentes com essas regras, que as ferramentas mais recentes leem automaticamente a cada tarefa. Assim você não precisa repetir o pedido toda vez, e o padrão vale para todo mundo que mexer no projeto depois.

E mantenha o hábito mais simples de todos: antes de qualquer coisa entrar no ar, abra o sistema em janela anônima e tente acessar o que não deveria estar acessível. É um teste de dois minutos que pega a falha mais frequente de todas.