Seu sistema feito com IA pode estar aberto sem você saber
Um pedido pronto para a IA auditar a segurança do que você já criou, sem mexer em nada sem o seu OK. Dica para vibecoders (quem cria sistema só conversando com a IA): cole este pedido na IA mais avançada que você tiver e peça um relatório de segurança antes de qualquer mudança. Você lê, escolhe o que faz sentido e só então autoriza as correções.

Ivan Lessa
@oivandigital · IA aplicada a negócios, sem hype

Serve pra você?
Passo a passo
Leva uns 10 minutos para começar. O tempo da análise depende do tamanho do seu sistema.
Abra a sua IA com o modelo mais avançado
Uma IA que trabalha na pasta do seu sistema (como o Claude Code ou o Codex). Escolha o modelo mais avançado que você tiver: uma revisão de segurança é um trabalho difícil. Na lista oficial da Anthropic (conferida em 09/10/2026) o modelo mais avançado é o Claude Fable 5.1, indicado para raciocínio exigente e trabalho longo; ele é mais lento e mais caro, e vale numa revisão que importa. Outra IA? Use a melhor que ela oferecer.
Cole o pedido e diga o que ela pode ler
Baixe o pedido na seção abaixo e cole o texto inteiro na IA. Em seguida, mande esta mensagem de escopo (troque o trecho entre parênteses):
Só leia: o relatório vem antes de qualquer mudança
A IA mapeia o sistema, procura problemas por área (login e acesso, banco de dados, APIs, tela, infraestrutura e falhas típicas de código feito por IA), classifica cada um (crítica, alta, média, baixa) e entrega um relatório com resumo, evidências (arquivo e linha) e plano de correção. Depois ela para e pergunta o que você autoriza.
Aprove correção por correção
Leia o resumo e escolha o que faz sentido para o seu caso. Responda com os itens que você autoriza (por exemplo: "autorizo C-01 e C-02, o resto fica para depois"). Silêncio ou um "pode analisar" não valem como permissão. Antes de mexer, peça uma cópia de segurança do projeto.
Teste e confira de novo
Depois de cada correção aprovada, a IA deve rodar os testes e conferir se algo quebrou. Peça para ela repetir a auditoria só nos itens corrigidos. O pedido manda dizer o que foi corrigido, o que ficou pela metade e quais riscos continuam. Ela nunca deve dizer que o sistema está 100% seguro.
A prova real: o que aconteceu no meu teste
Teste em 09/10/2026, num app pequeno inventado por nós, com falhas colocadas de propósito.
- O app de teste"Pedidos Express": um sistema de pedidos de lanchonete inventado, com 138 linhas de Python (Flask e SQLite) e uma tela. Dados de mentira. Colocamos 12 falhas comuns de propósito e anotamos num gabarito antes de rodar a auditoria.
- Como rodamosO pedido do Ivan, sem alterações, mais uma mensagem de escopo, no Claude Code em modo de só leitura (a IA só podia ler os arquivos), num modelo oficial da Anthropic: claude-fable-5-1 (Claude Fable 5.1). Em uma pasta temporária, fora dos projetos do Ivan. Levou cerca de 4 minutos e 20 segundos e custou US$ 1,69 em uso de API (valor de lista).
- O que ela entregouUm relatório com 23 achados: 6 críticos, 6 altos, 4 médios, 3 baixos e 4 informativos, cada um com arquivo e linha, e um plano de correção em lotes. No fim ela parou e perguntou: "Quais correções você autoriza implementar?". Nada foi alterado.
- Quanto acertouDas 12 falhas plantadas, encontrou as 12. Não acusou falha nas partes que estavam certas (a busca de produtos, que usava consulta segura, saiu como "sem achado"). Achou ainda problemas reais que não plantamos de propósito, como falta de proteção contra CSRF e de cabeçalhos de segurança.
- O que isto NÃO provaFoi um app pequeno, um modelo, uma única vez e só leitura do código (a IA não executou nada). Em outro sistema e em outra rodada o resultado pode ser diferente: a IA pode deixar passar problemas ou apontar coisas que não são problema. Por isso o relatório precisa ser lido por uma pessoa.
As 12 falhas plantadas e o que a IA achou
| Falha plantada | Achado da IA | Gravidade dada |
|---|---|---|
| Injeção de SQL na busca | V03 SQL Injection em /buscar | Crítica |
| Qualquer usuário lê pedido de outro (IDOR) | V07 IDOR em /pedidos/id | Alta |
| Rotas de admin sem checagem | V01 Endpoints admin sem autenticação | Crítica |
| Segredos escritos no código | V05 chave de sessão fixa e V11 chave de pagamento no código | Crítica e Alta |
| Total do pedido vem do navegador | V09 Regra de negócio burlável | Alta |
| CORS aberto com credenciais | V08 CORS refletindo Origin com credenciais | Alta |
| Login sem limite de tentativas | V14 Sem proteção contra força bruta | Média |
| Senhas em texto simples | V02 Senhas em texto claro | Crítica |
| Cliente vira admin no cadastro | V04 Escalada de privilégio por mass assignment | Crítica |
| Debug ligado e aberto na rede | V06 Debug ligado em todas as interfaces | Crítica |
| Script malicioso no pedido (XSS) | V10 XSS armazenado | Alta |
| Erro mostra a consulta SQL | V13 Tratamento de erros vaza detalhes | Média |
Baixe o pedido de auditoria
O pedido completo, exatamente como eu escrevi: 12 seções, da regra de não mexer em nada sem aprovação até a validação final. Texto simples, abre em qualquer editor. Grátis.
Ler o texto completo (9 KB)
# AUDITORIA COMPLETA DE SEGURANÇA DA INFORMAÇÃO E CORREÇÃO CONTROLADA DE VULNERABILIDADES ## 1. PAPEL Atue como uma equipe sênior de especialistas em: - Segurança da Informação e Cibersegurança - Ethical Hacking e Pentest autorizado - Segurança de Aplicações (AppSec) - DevSecOps e Segurança de Infraestrutura - Arquitetura de Software Seguro - Segurança de APIs e Bancos de Dados - Segurança de sistemas desenvolvidos por Inteligência Artificial - Proteção de Dados e conformidade com a LGPD Utilize como referências OWASP Top 10, OWASP ASVS, OWASP API Security Top 10, NIST Cybersecurity Framework, CIS Controls e práticas de desenvolvimento seguro. ## 2. OBJETIVO PRINCIPAL Realizar uma auditoria abrangente de segurança no sistema disponibilizado, identificando vulnerabilidades, configurações inseguras, falhas arquiteturais, riscos de exposição de informações e problemas de segurança no código-fonte. Para cada vulnerabilidade encontrada, apresentar evidências, explicar os riscos, recomendar correções e preparar um plano de implementação. *REGRA ABSOLUTA: NENHUMA CORREÇÃO, ALTERAÇÃO DE CÓDIGO, CONFIGURAÇÃO, BANCO DE DADOS OU INFRAESTRUTURA PODERÁ SER IMPLEMENTADA SEM MINHA APROVAÇÃO EXPLÍCITA.* ## 3. REGRAS DE EXECUÇÃO 1. Inicialmente, trabalhe exclusivamente em modo de análise e leitura. 2. Examine apenas sistemas, repositórios e ambientes expressamente autorizados. 3. Não execute testes destrutivos, exploração ativa, força bruta ou varreduras invasivas sem autorização específica. 4. Não altere arquivos, dependências, permissões, credenciais ou configurações durante a auditoria. 5. Não exponha senhas, tokens, chaves privadas ou dados pessoais nos relatórios. 6. Não considere uma vulnerabilidade confirmada sem evidência suficiente. 7. Diferencie vulnerabilidades confirmadas, suspeitas e riscos potenciais. 8. Se não possuir acesso a algum componente, informe a limitação. Nunca declare que examinou algo que não conseguiu acessar. 9. Antes de qualquer implementação, apresente as alterações propostas e aguarde aprovação. 10. Após cada implementação aprovada, realize testes e verifique possíveis regressões. ## 4. ETAPA 1 — MAPEAMENTO COMPLETO DO SISTEMA Identifique e documente: - Linguagens de programação e frameworks - Estrutura do projeto e arquitetura - Frontend, backend e serviços - APIs internas e externas - Bancos de dados e mecanismos de armazenamento - Serviços de autenticação e autorização - Integrações com terceiros - Serviços de nuvem e infraestrutura - Dependências e bibliotecas - Variáveis de ambiente e gerenciamento de segredos - Fluxos de dados sensíveis - Componentes gerados ou integrados por IA Crie um inventário técnico e identifique as superfícies de ataque. ## 5. ETAPA 2 — ANÁLISE DE VULNERABILIDADES ### A. Autenticação e controle de acesso Verifique: - Autenticação insegura - Senhas armazenadas inadequadamente - Falhas na recuperação de senhas - Ausência de proteção contra tentativas abusivas de login - Falhas em JWT e gerenciamento de sessões - Escalonamento indevido de privilégios - Acesso não autorizado a funcionalidades administrativas - IDOR/BOLA e problemas de autorização por objeto - Ausência de MFA em operações críticas ### B. Banco de dados Investigue: - SQL Injection e NoSQL Injection - Políticas de acesso excessivamente permissivas - Exposição de tabelas e registros sensíveis - Falhas em Row Level Security (RLS), quando aplicável - Consultas inseguras - Credenciais expostas - Falta de criptografia adequada - Ausência de estratégias seguras de backup e recuperação ### C. APIs e backend Analise: - Endpoints desprotegidos - Falhas de autenticação e autorização - Ausência de validação de entrada - Exposição excessiva de dados - CORS inseguro - Falta de rate limiting - Tratamento inadequado de erros - SSRF, command injection e outras falhas de injeção - Configurações inseguras de upload de arquivos - Falhas na validação de webhooks ### D. Frontend Examine: - Cross-Site Scripting (XSS) - Cross-Site Request Forgery (CSRF) - Armazenamento inseguro de tokens - Vazamento de informações no navegador - Dependências vulneráveis - Configurações inadequadas de segurança HTTP - Exposição de informações internas no código cliente ### E. Infraestrutura e DevSecOps Verifique: - Configurações de ambiente - Permissões de serviços - Containers e imagens - Dependências desatualizadas - Segredos em repositórios e logs - Segurança dos pipelines CI/CD - HTTPS e configurações TLS - Monitoramento e registros de auditoria - Backups e recuperação de desastres ### F. Vulnerabilidades relacionadas ao desenvolvimento por IA Procure especificamente: - Código gerado com validações incompletas - Autorização implementada apenas no frontend - Endpoints criados sem proteção adequada - Segredos inseridos diretamente no código - Regras de negócio que podem ser contornadas - Falhas de isolamento entre usuários - Componentes que confiam excessivamente em dados externos - Bibliotecas sugeridas pela IA sem verificação de segurança - Falhas na integração entre módulos gerados separadamente Se o sistema utilizar modelos de IA em produção, avalie também: - Prompt injection - Vazamento de informações por respostas do modelo - Acesso indevido a ferramentas conectadas à IA - Tratamento inseguro de documentos e conteúdos externos - Ausência de validação de ações propostas pela IA - Permissões excessivas concedidas a agentes automatizados ## 6. ETAPA 3 — CLASSIFICAÇÃO DOS RISCOS Para cada problema encontrado, apresente: - Identificador único - Nome da vulnerabilidade - Componente afetado - Arquivo, função, endpoint ou configuração relacionada - Descrição técnica - Evidência observada, sem divulgar segredos - Impacto potencial - Probabilidade de exploração - Classificação de severidade: Crítica, Alta, Média, Baixa ou Informativa - CVSS, quando aplicável e justificável - Referência CWE/OWASP, quando aplicável - Status: Confirmada, Suspeita ou Risco Potencial - Recomendação técnica de correção Priorize as vulnerabilidades considerando gravidade, exposição, explorabilidade e impacto no negócio. ## 7. ETAPA 4 — PLANO DE CORREÇÃO Para cada vulnerabilidade, proponha: 1. Solução recomendada. 2. Arquivos e componentes que precisarão ser modificados. 3. Descrição das alterações necessárias. 4. Benefícios de segurança esperados. 5. Possíveis impactos no funcionamento do sistema. 6. Dependências e pré-requisitos. 7. Testes necessários para validar a solução. 8. Estratégia de rollback. 9. Estimativa de complexidade. 10. Prioridade de implementação. Sempre que possível, apresente patches ou diffs propostos para revisão, sem aplicá-los. ## 8. ETAPA 5 — RELATÓRIO E APROVAÇÃO Antes de qualquer alteração, entregue: *RELATÓRIO EXECUTIVO* - Visão geral da segurança do sistema - Quantidade de vulnerabilidades por severidade - Principais riscos - Limitações da auditoria - Prioridades de correção *RELATÓRIO TÉCNICO* - Evidências - Localização dos problemas - Causas prováveis - Soluções propostas - Testes recomendados *PLANO DE IMPLEMENTAÇÃO* - Correções organizadas por prioridade - Alterações previstas - Riscos de implementação - Procedimentos de validação e rollback Após apresentar os relatórios, interrompa a execução e pergunte: "Identifiquei as vulnerabilidades e preparei o plano de correção. Quais correções você autoriza implementar?" Não interprete silêncio, respostas genéricas ou autorização para analisar como permissão para modificar o sistema. ## 9. ETAPA 6 — IMPLEMENTAÇÃO APÓS APROVAÇÃO Somente após minha aprovação explícita para correções específicas: 1. Confirme o escopo exato autorizado. 2. Verifique a existência de backup ou mecanismo de rollback. 3. Prepare as alterações em branch ou ambiente isolado, quando disponível. 4. Implemente exclusivamente as correções aprovadas. 5. Preserve as funcionalidades existentes. 6. Evite mudanças desnecessárias na arquitetura. 7. Execute testes automatizados e verificações de segurança. 8. Registre cada alteração realizada. 9. Apresente o resultado para revisão. 10. Solicite nova autorização antes de qualquer implantação em produção. Caso uma correção exija mudanças adicionais fora do escopo aprovado, interrompa a execução e solicite nova autorização. ## 10. ETAPA 7 — VALIDAÇÃO FINAL Após a implementação, realize: - Revisão das alterações - Testes unitários e de integração disponíveis - Testes de regressão - Reavaliação das vulnerabilidades corrigidas - Verificação de permissões - Validação dos mecanismos de autenticação - Verificação de exposição de informações - Revisão das dependências afetadas Classifique cada vulnerabilidade como: - Corrigida e validada - Implementada, aguardando validação - Parcialmente corrigida - Não corrigida - Risco aceito mediante decisão explícita Não declare que o sistema está 100% seguro. Informe os riscos residuais e as limitações dos testes. ## 11. FORMATO DE ENTREGA Organize os resultados em: 1. Resumo executivo 2. Inventário e arquitetura analisada 3. Vulnerabilidades identificadas 4. Matriz de riscos 5. Recomendações técnicas 6. Plano de correção priorizado 7. Solicitação formal de aprovação 8. Registro de implementação, após aprovação 9. Resultados dos testes e riscos residuais ## 12. INSTRUÇÃO PARA INICIAR Comece perguntando quais repositórios, arquivos, tecnologias e ambientes estão disponíveis para análise e qual é o escopo autorizado. Depois, realize o mapeamento e a auditoria em modo somente leitura.
Glossário para leigos
- VibecoderQuem cria sistemas conversando com a IA, sem escrever o código à mão.
- VulnerabilidadeUma brecha no sistema que alguém mal-intencionado poderia usar.
- Autenticação e autorizaçãoAutenticação é provar quem você é (o login). Autorização é o que você pode fazer depois de entrar.
- IDORQuando dá para ver o dado de outra pessoa só trocando um número na página (por exemplo, o número do pedido).
- Injeção de SQLEscrever um texto malicioso em um campo para fazer o banco de dados entregar o que não devia.
- XSSUm texto que vira um pequeno programa quando aparece na tela de outra pessoa.
- CORSA regra que diz quais outros sites podem conversar com o seu sistema. Aberto demais, qualquer site pode.
- RollbackVoltar atrás: o jeito de desfazer uma mudança que deu errado.
- CWE e OWASPListas públicas de tipos de falha (CWE) e das mais comuns em sistemas (OWASP). A IA usa esses nomes no relatório.
- Somente leituraA IA só olha os arquivos. Não escreve, não instala e não roda nada.
Fontes oficiais (conferidas em 09/10/2026)
- OWASP Top 10A lista dos 10 riscos mais comuns em aplicações web.owasp.org ↗
- OWASP ASVSPadrão de verificação de segurança de aplicações.owasp.org ↗
- OWASP API Security Top 10Os riscos mais comuns em APIs (inclui o IDOR).owasp.org ↗
- CWE Top 25As falhas de software mais perigosas, segundo o MITRE.cwe.mitre.org ↗
- Lei Geral de Proteção de Dados (LGPD)O texto da Lei 13.709/2018.planalto.gov.br ↗
- ANPDAutoridade Nacional de Proteção de Dados: orientações e comunicação de incidentes.gov.br/anpd ↗
- Modelos da AnthropicA lista oficial de modelos Claude, com IDs e descrições.platform.claude.com ↗
- Claude CodeA documentação oficial da IA que trabalha na sua pasta.code.claude.com ↗
Quando chamar um profissional
Isso é só a ponta do iceberg.
Na sua empresa de verdade entram modelos mais avançados, que não treinam com os seus dados, mais segurança e LGPD. Na Imersão de IA para o seu negócio, eu coloco a IA para trabalhar com limites definidos por você.


