Pular para o conteúdo
PixelCorp SpaceEstúdio de IA corporativa/ skills para o seu negócio
Dica para vibecoders

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

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

Não precisa ser programador, basta saber pedir

Baixar o pedido ↓

Imagem de capa: Seu sistema feito com IA pode estar aberto sem você saber

Serve pra você?

Se você está criando um sistema, um aplicativo ou um site conversando com a IA e não é da área de segurança, este pedido é para você. A IA entrega funcionalidades rápido, mas nem sempre lembra de trancar as portas: área de administrador aberta, senha guardada em texto simples, um cliente que consegue ler os dados de outro. Este pedido manda a IA agir como uma equipe de segurança e só olhar: ela lista os problemas, explica o risco e propõe um plano. Nada é alterado sem a sua aprovação. Serve para melhorar a segurança do que já foi feito. Para criar um sistema direito desde o início, veja o prompt padrão.

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):

Escopo autorizado: somente os arquivos desta pasta (o meu sistema, descreva aqui em uma frase o que ele faz). Pode ler os arquivos, em modo somente leitura. Não rode nada, não instale nada e não altere nada. Faça o mapeamento e a auditoria (etapas 1 a 5), entregue os relatórios e PARE na pergunta de aprovação. Não existe etapa de correção nesta rodada.

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 plantadaAchado da IAGravidade dada
Injeção de SQL na buscaV03 SQL Injection em /buscarCrítica
Qualquer usuário lê pedido de outro (IDOR)V07 IDOR em /pedidos/idAlta
Rotas de admin sem checagemV01 Endpoints admin sem autenticaçãoCrítica
Segredos escritos no códigoV05 chave de sessão fixa e V11 chave de pagamento no códigoCrítica e Alta
Total do pedido vem do navegadorV09 Regra de negócio burlávelAlta
CORS aberto com credenciaisV08 CORS refletindo Origin com credenciaisAlta
Login sem limite de tentativasV14 Sem proteção contra força brutaMédia
Senhas em texto simplesV02 Senhas em texto claroCrítica
Cliente vira admin no cadastroV04 Escalada de privilégio por mass assignmentCrítica
Debug ligado e aberto na redeV06 Debug ligado em todas as interfacesCrítica
Script malicioso no pedido (XSS)V10 XSS armazenadoAlta
Erro mostra a consulta SQLV13 Tratamento de erros vaza detalhesMédia
Cuidados: Use só em sistema seu ou com autorização por escrito de quem é o dono. Não cole senhas, chaves ou dados reais de clientes na conversa: o pedido manda a IA não expor segredos, mas o melhor é nem entregar. A IA pode errar e deixar passar problemas; não substitui um profissional de segurança, e nenhum teste garante que um sistema está 100% seguro. Se o sistema guarda dados de clientes, a LGPD (Lei 13.709/2018) se aplica: em caso de dúvida ou de vazamento, procure um profissional e leia as orientações da ANPD. Este conteúdo não é consultoria jurídica nem de segurança.

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.

Baixar o pedido (.md)
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.

Quando chamar um profissional

Chame um profissional de segurança se o sistema guarda dados de clientes, recebe pagamentos, é usado por muita gente ou se você recebeu um alerta de invasão. A auditoria da IA é um primeiro filtro barato, não um laudo. Texto baseado em um teste de 09/10/2026; versões de modelos e documentação mudam.

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ê.

Veja também

Gostou? Me siga e receba mais.

Toda semana, uma ferramenta de IA explicada para quem tem negócio. Comente AUDITORIA no Instagram e eu te mando os links.