Esta lista é baseada nos padrões mais comuns que encontramos ao revisar sistemas construídos com apoio de IA. Nenhum deles é um "bug raro" — são configurações que a maioria das ferramentas simplesmente não configura por padrão, porque isso exigiria saber que o risco existe.
1. Chave de acesso privada exposta no navegador
Todo sistema que usa um banco de dados ou serviço externo (como processamento de pagamento) precisa de uma "chave" para se autenticar com esse serviço. Existem chaves públicas, feitas para rodar no navegador do visitante, e chaves privadas, que deveriam ficar só no servidor.
É comum a IA colocar a chave errada no lugar errado — uma chave privada, com acesso total ao banco de dados, dentro do código que qualquer visitante do site consegue abrir e ler. Isso equivale a deixar a chave mestra da loja pendurada na vitrine.
2. Banco de dados sem separação real entre usuários
A maioria dos bancos de dados modernos tem um recurso chamado RLS (Row Level Security, ou segurança em nível de linha), que garante que cada usuário só consiga ler e alterar os próprios dados. Sem essa configuração ativa e correta, um usuário logado pode conseguir ler os dados de qualquer outro cliente do sistema só trocando um número na requisição.
Esse é, na nossa experiência, o erro mais comum e o mais grave: ele transforma qualquer conta de cliente comum em uma porta de entrada para os dados de todo mundo.
3. Rota administrativa sem checagem real
É comum o painel administrativo estar "escondido" apenas na tela: o sistema só mostra o botão de admin para quem tem a permissão certa. O problema é quando essa checagem existe só na aparência da tela, e a rota que executa a ação por trás não confere de novo quem está chamando.
Nesse cenário, qualquer usuário comum que descubra o endereço da rota administrativa (o que não é difícil, basta olhar as requisições que o próprio navegador faz) consegue executar ações de administrador sem ter permissão nenhuma.
4. Webhooks que confiam em quem os chama
Um webhook é o mecanismo que avisa o seu sistema quando algo acontece do lado de fora — por exemplo, quando um pagamento é aprovado no Mercado Pago ou Stripe. O erro comum é o sistema acreditar cegamente em qualquer notificação que chega nesse endereço, sem confirmar com o próprio provedor de pagamento se aquilo realmente aconteceu.
Sem essa confirmação, alguém poderia forjar uma notificação de "pagamento aprovado" para liberar um produto ou serviço sem pagar de verdade.
5. Formulários e rotas sem limite de repetição
Formulários públicos (contato, cadastro, "esqueci minha senha") e até rotas que exigem login costumam não ter limite de quantas vezes podem ser chamados em sequência. Isso abre espaço para abuso de envio de e-mail (conhecido como email bomb), esgotamento da cota de um serviço pago, ou simplesmente sobrecarga do sistema.
Documentamos um caso real desse último tipo, incluindo como foi corrigido, no relato da nossa auditoria interna.
O padrão por trás dos cinco erros
Repare que nenhum desses problemas exige um invasor genial. Todos eles são sobre uma trava que deveria existir e não existe. É exatamente esse tipo de lacuna, simples e comum, que uma auditoria de segurança existe para encontrar antes que alguém — mal-intencionado ou não — tropece nela.