Você só sabe fazendo uma auditoria antes de publicar, que pode ser somente leitura: olhar código, configuração e dependências sem mexer em nada. O roteiro mais usado é o chamado OWASP Top 10, a lista aberta dos dez riscos mais comuns em aplicações web. Em sistema feito com IA, comece por chave no código e rota sem login.
O sistema funciona na demonstração, o cliente consegue se cadastrar, o painel abre bonito. É justamente aí que mora o risco. A IA que escreveu o código foi otimizada para fazer funcionar, não para resistir a quem quer entrar sem convite.
O que é o OWASP Top 10 e por que ele serve de checklist?
O OWASP é uma fundação sem fins lucrativos que mantém, de forma aberta, a lista dos dez riscos mais frequentes em aplicações web. A edição atual é a OWASP Top 10:2025, e ela serve de checklist porque cada categoria vira uma pergunta que dá para responder olhando o sistema.
Não é norma nem certificação. É um mapa de onde os problemas costumam aparecer, montado a partir de dados de testes reais. Para quem não é da área, a utilidade prática é outra: ele impede que a revisão dependa da memória de quem está olhando.
Quais são as dez categorias da edição 2025?
A lista oficial, na ordem em que a própria fundação publica, com a pergunta que cada item vira na hora de revisar:
| Código | Categoria | A pergunta na revisão |
|---|---|---|
| A01 | Controle de acesso quebrado | Um usuário consegue ver ou mudar o que é de outro? |
| A02 | Configuração de segurança errada | Ficou algo no modo “teste” ou aberto por padrão? |
| A03 | Falhas na cadeia de suprimentos de software | As bibliotecas usadas têm falha conhecida? |
| A04 | Falhas de criptografia | Senha e dado sensível estão protegidos? |
| A05 | Injeção | O que o usuário digita pode virar comando? |
| A06 | Design inseguro | O fluxo foi pensado para quem tenta burlar? |
| A07 | Falhas de autenticação | Login e sessão resistem a abuso? |
| A08 | Falhas de integridade de software ou dados | Dá para confiar no que chega de fora? |
| A09 | Falhas de registro e alerta | Se alguém invadir, você fica sabendo? |
| A10 | Tratamento incorreto de condições excepcionais | Quando algo dá erro, o sistema falha fechado? |
O que costuma escapar num sistema construído com IA?
Os furos de sistema gerado por IA são previsíveis, porque o gerador sempre corta o mesmo caminho para o código rodar logo. No roteiro de auditoria que usamos, eles viraram uma lista própria, conferida antes de todo o resto:
- Chave de API (a senha que abre a porta de outro sistema) escrita direto no código ou exposta na parte que roda no navegador do visitante
- Rota sem autenticação: o endereço da API responde a quem não fez login
- Consulta que não confere o dono: basta trocar o número do cadastro na URL para ver o de outra pessoa
- Banco com regra de acesso desligada ou em modo de teste, como acontece em plataformas tipo Supabase e Firebase
- Chave de administrador no lado do cliente, que ignora qualquer regra de acesso
- Validação só na tela, sem conferência no servidor (o computador que guarda os dados e responde aos pedidos)
Quase todos caem no A01 da lista. Não por acaso, a página oficial dessa categoria registra que ela apareceu em 100% das aplicações testadas.
Por que a auditoria precisa ser somente leitura?
Porque o sistema que você quer proteger às vezes já está no ar, com dado de cliente de verdade. Uma revisão que testa ataque contra produção pode derrubar serviço, criar registro falso ou apagar informação — e aí o estrago veio da própria checagem.
A regra que seguimos separa duas coisas. Ler código, configuração, histórico de versões e lista de dependências é sempre seguro. Isso pode ser feito direto. Qualquer teste ativo contra produção, como enviar dados maliciosos a um formulário ou criar conta de teste, só acontece depois de montado, explicado e aprovado por uma pessoa.
Como resolver isso com IA, passo a passo?
1. O que construir. Uma skill de auditoria no Claude Code (uma skill é um conjunto de instruções salvas que a IA segue sempre do mesmo jeito), somente leitura, que confere o sistema contra o OWASP Top 10 e os seis furos típicos de código feito por IA. Ela entrega um relatório com cada achado, a prova (arquivo, linha ou configuração), a gravidade e a correção sugerida. É o desenho da auditoria que usamos.
A auditoria que rodamos foi construída com o Claude Code e vive como um roteiro fixo, não como pergunta solta a um chat. Ela olha o sistema em 3 camadas (código, dados e privacidade, servidor), percorre 8 fases e se apoia em 10 guias de referência, um deles só para os furos típicos de sistema feito com IA.
| Peça | O que faz |
|---|---|
| Varredura de segredos | Procura chave e senha no código e no histórico de versões |
| Auditoria de dependências | Lista biblioteca com falha conhecida |
| Checagem de cabeçalhos | Olha de fora proteções do navegador, conexão segura e origens permitidas |
| Consulta de regras do banco | Lista tabelas sem regra de acesso por linha, rodada pelo próprio dono |
São 4 scripts (pequenos programas que fazem a checagem sozinhos), todos de leitura. Cada achado sai com severidade, explicação em português simples e correção sugerida, e o conjunto fecha com uma nota de A a F.
2. O pedido pronto para copiar. O pedido que recomendamos colar no Claude Code, aberto na pasta do sistema:
“Crie uma skill chamada ‘auditar antes de publicar’, somente leitura: ela não pode alterar nenhum arquivo, nem enviar nada para o sistema no ar. Ela deve conferir o projeto contra as dez categorias do OWASP Top 10:2025 e, antes de tudo, contra estes furos: chave de API no código ou no histórico de versões, rota que responde sem login, consulta que não confere o dono do cadastro, banco com regra de acesso desligada, chave de administrador no lado do navegador e validação feita só na tela. Para cada item, mostre a prova: arquivo, linha ou configuração. Nunca mostre uma chave por inteiro; mascare. Termine com uma nota de A a F e um plano de correção em ordem de gravidade, sem corrigir nada sozinha. Explique tudo em português simples.”
Como conferir se a auditoria de IA acertou?
3. O teste da chave plantada. Faça uma cópia de teste do sistema e plante dois furos da lista deste artigo. Primeiro, escreva uma chave falsa no código, salve no histórico e depois apague a linha. Segundo, deixe uma rota respondendo sem login. A skill certa acha a chave mesmo apagada, porque ela continua no histórico, e mostra a chave mascarada. E classifica a rota aberta no A01, a categoria que a OWASP registrou em 100% das aplicações testadas. Se ela responder só “está seguro”, está reprovada.
Quanto custa e quanto tempo leva para montar a auditoria?
4. Custo e tempo. A skill roda no Claude Code. A página oficial de preços do Claude, vista do Brasil em 02/10/2026, mostra o plano Pro a R$ 110 no mensal ou R$ 92 por mês no anual (R$ 1.100 de uma vez), com o Claude Code incluído. O plano Free é R$ 0 e não inclui o Claude Code. Os preços não incluem impostos aplicáveis. A lista do OWASP é aberta e não custa nada. O tempo para montar e rodar depende do tamanho do sistema; não medimos esse número à parte.
E quando a auditoria encontra um problema?
Primeiro, nada é corrigido automaticamente. O relatório lista os achados e um plano em ordem de gravidade; a correção acontece com aprovação, uma de cada vez, começando pelas críticas.
Segundo, segredo encontrado nunca aparece por inteiro no relatório: ele sai mascarado, com a recomendação de trocar a chave. Apagar a linha do código não basta, porque ela continua no histórico. É o que o guia de gestão de segredos da OWASP orienta: chave exposta deve ser revogada imediatamente e substituída por uma nova.
Quem pode fazer essa revisão se eu não sou técnico?
Você mesmo pode fazer a primeira passada, desde que você trate a IA como auditora e não como quem aprova o próprio trabalho. A diferença está em pedir a revisão contra uma lista fechada, como as dez categorias acima e os seis furos típicos, e exigir evidência para cada item: o arquivo, a linha, a configuração.
“Está seguro?” é uma pergunta que qualquer ferramenta responde com um sim confiante. “Mostre onde cada rota confere o login” só tem resposta se o trabalho foi feito. É o mesmo princípio de conferir o que a automação diz ter salvo, que contamos em o que fazer quando a automação que a IA construiu quebra.
Quando essa revisão deve acontecer?
Em dois momentos, e usamos os dois modos. O modo construir entra enquanto o sistema nasce: a regra da casa, desde julho de 2026, é que todo app, API ou página siga o OWASP Top 10 como padrão, com chave fora do código e autorização checada no servidor. O modo auditar entra antes de publicar, com nota de 0 a 10 por categoria.
Tratar segurança como etapa final, depois que “ficou pronto”, é o que faz o furo ir junto para o ar. Custa menos prevenir do que descobrir pelo cliente.
O que muda depois de ter esse checklist
Você deixa de publicar com base no “funcionou na tela” e passa a publicar com uma lista conferida item por item, com prova. A segurança do sistema construído é um assunto; a do dado que você manda para a IA é outro, e está em é seguro usar IA com os dados dos meus clientes.
Em quais casos essa auditoria se aplica bem — e quando não?
Ela se aplica bem nos seguintes casos:
- Sistema com login, em que cada pessoa só pode ver o que é dela. É o terreno do A01.
- Sistema que guarda dado de cliente, como cadastro, pedido ou contato.
- Sistema que conversa com outros serviços por chave, como pagamento ou envio de mensagens.
- Sistema que já está no ar e vai ganhar uma função nova.
Ela pede menos esforço num protótipo que só roda no seu computador, sem dado real e sem endereço na internet. Ali, o modo construir basta por enquanto.
Mas o protótipo não pula a auditoria. Ela só muda de hora: entra no dia em que ele for para o ar.
O que a gente faria no seu lugar?
Nós não publicaríamos nenhum sistema com login ou dado de cliente sem conferir primeiro o controle de acesso. O motivo está no próprio artigo. A categoria A01 apareceu em 100% das aplicações testadas, e quase todos os furos típicos de código feito por IA caem nela.
Faríamos a auditoria somente leitura antes de tudo, com a skill “auditar antes de publicar” do passo a passo acima e o teste da chave plantada feito uma vez para confiar nela. Qualquer teste ativo ficaria para depois, com aprovação de uma pessoa.
O que não faríamos: perguntar “está seguro?” para a mesma IA que escreveu o código e aceitar o sim. Também não deixaríamos a correção rodar sozinha. E não apagaríamos uma chave exposta sem trocá-la por uma nova.
Em resumo
Sistema feito com IA fica seguro para publicar quando passa por uma auditoria somente leitura, guiada pelas dez categorias do OWASP Top 10 e pelos furos típicos de código gerado, como chave no código e rota sem login. A revisão não corrige nada sozinha: ela aponta, dá nota e deixa a correção para depois de aprovada, começando pelo que é crítico.
Este artigo faz parte do pilar Eu não sou programador — dá pra construir com IA mesmo assim?.
Deixe um comentário