Salve rapazeada, há uns dias atrás eu gravei esse vídeo:
Eu falo das falhas de seguranças mais comum nos SaaS, vídeo bateu mais de 100 mil views em pouco tempo e gerou uma repercussão boa.
Daí um dos inscritos me deu um feedback sobre os resultados e o que poderia ser melhorado no PROMPT, daí resolvi fazer a V2 e pra garantir que ele funciona em qualquer projeto, eu busquei 4 SaaS aleatórios com tecnologias diferentes e executei o prompt, tá documentado nesse vídeo aqui:
🤖 O prompt (copia e cola no Claude Code, Cursor, OpenCode, no que você usar)
Abre o teu agente na raiz do projeto e cola isso inteiro:
Revisa este código atrás de cinco falhas de segurança. Antes de começar, detecte a stack do projeto (linguagem, framework, ORM/query builder, mecanismo de auth, frontend, arquivos de deploy como Docker/CI/Helm/Terraform) e adapte cada categoria ao equivalente dessa stack:
1. BANCO SEM TRANCA (isolamento de inquilino/dono) — em Supabase é RLS ausente; em APIs próprias são queries de listagem/busca/agregação/relatório/exportação que não filtram pelo usuário autenticado ou pela organização/workspace/tenant ao qual ele pertence. Identifique primeiro QUAL é o mecanismo de isolamento do projeto (RLS, middleware de tenant, filtro manual por user_id, etc.) e aponte onde ele está ausente ou furado.
2. PERMISSÃO DEFINIDA NO NAVEGADOR — operações privilegiadas (admin, configurações, gestão de usuários, ações de escrita) em que o frontend esconde a UI por papel (isAdmin, canEdit, role...) mas o servidor NÃO faz a verificação equivalente. Cruze cada gate de papel do frontend com o endpoint correspondente e confirme se o backend valida o privilégio em toda rota sensível.
3. IDOR — rotas que buscam, alteram ou deletam um objeto por ID (path, query ou body) sem verificar se o objeto pertence ao usuário/tenant do chamador. Percorra sistematicamente TODOS os handlers de rota do backend, não amostras.
4. CHAVES EXPOSTAS (hardcode) — API keys, tokens, senhas, segredos de assinatura (JWT, webhooks), chaves privadas e credenciais padrão embutidos no código-fonte, configs, docker-compose, charts, CI, scripts e documentação. Atenção especial a defaults públicos que viram segredo real se não forem sobrescritos (ex: ${VAR:-valor-default}) e à ausência de validação de startup que rejeite esses defaults. Verifique também o histórico git por segredos commitados e o bundle do frontend por chaves embutidas.
5. INPUTS SEM TRATAMENTO (XSS) — no frontend: innerHTML/dangerouslySetInnerHTML/equivalentes do framework (v-html, [innerHTML], dangerouslySet...), renderização de markdown/HTML sem sanitização, URLs controladas por usuário em href/src (javascript:), eval/new Function. No backend: input do usuário entrando em HTML de e-mails, templates ou respostas sem escape. Verifique se existe lib de sanitização no projeto e se ela é aplicada nos pontos encontrados.
REGRAS DA AUDITORIA:
- Reporte apenas achados verificados no código real. Nada de especulação. Para cada achado: caminho do arquivo, número(s) exato(s) da linha, trecho do código, por que é explorável e severidade (crítica/alta/média/baixa/informativa).
- Liste arquivo por arquivo, linha por linha.
- Registre também o que foi verificado e está CORRETO (ex: "router X valida posse em todos os handlers") — isso vira a seção de pontos fortes e prova a cobertura da auditoria.
- Quando a categoria não se aplicar à stack (ex: projeto sem frontend), diga isso explicitamente em vez de forçar achados.
- Note condições de explorabilidade (feature flags, config insegura necessária, etc.).
DEPOIS DA AUDITORIA, gere um RELATÓRIO EM PDF, visualmente amigável, em pt-BR, salvo em docs/security-audit/relatorio-auditoria-seguranca.pdf, contendo:
a) Capa: título "Relatório de Auditoria de Segurança — <nome do projeto>", data, escopo auditado e nota metodológica (como cada categoria foi mapeada para a stack detectada).
b) Resumo executivo: total de achados por severidade, gráfico de rosca por severidade e gráfico de barras por categoria. Paleta: crítica #B91C1C, alta #EA580C, média #D97706, baixa #2563EB, ponto forte #059669.
c) Pontos fortes (o que está protegido, com evidência) e pontos fracos (os riscos centrais).
d) Tabela de achados detalhados por categoria: Severidade | Arquivo:linha | Descrição, com chip de severidade colorido.
e) Recomendações priorizadas (P1, P2, P3...).
f) AO FINAL DO PDF, uma seção "ISSUES PARA O GITHUB": para cada achado acionável, o texto COMPLETO de uma issue em Markdown, pronto para copiar e colar, dentro de um bloco delimitado (ex: entre --- ISSUE n --- e --- FIM ISSUE n ---). Cada issue deve conter:
- Título no formato "[Segurança] <descrição curta da falha>"
- Labels sugeridas: security + severidade
- Descrição do problema e por que é explorável
- Evidência: arquivo:linha com trecho de código
- Impacto
- Sugestão de correção
- Critérios de aceite (checklist verificável)
Agrupe achados triviais relacionados numa issue única quando fizer sentido (ex: vários defaults de segredo no mesmo tema), para não gerar spam de issues.
GERAÇÃO DO PDF — REGRAS TÉCNICAS:
- Não instale nada globalmente. Use ambiente isolado (venv Python com reportlab+matplotlib, ou ferramenta equivalente da stack local; se houver navegador headless/wkhtmltopdf/pandoc disponível, HTML→PDF também vale).
- Deixe o script gerador em docs/security-audit/ para regerar o relatório depois.
- Verifique o PDF gerado: número de páginas, renderização dos gráficos e legibilidade das tabelas (rasterize as páginas se possível). Corrija defeitos visuais antes de entregar.
- Páginas A4, margens ~2cm, cabeçalho/rodapé com nome do relatório e número de página.
Me entregue ao final: o relatório em PDF, a lista de achados no chat (arquivo por arquivo, linha por linha) e o caminho de todos os arquivos gerados.🧠 O que tem de novo na versão desse prompt?
1️⃣ Ele detecta a stack antes de procurar.
“RLS desligado” só existe em Supabase. Se o teu projeto é Rails, Laravel, Next ele faz um filtro manual por user_id, middleware de tenant, scope no ORM.
2️⃣ Análise linha por linha
Ele acha a falha e aponta exatamente a linha que está com problema, por exemplo:
“
routes/orders.ts:42busca por ID sem checar o dono”
A versão anterior ele dizia apenas:
“Você tem problema de IDOR”
3️⃣ Ele vasculha o histórico do Git.
O prompt anterior o foco era a codebase, essa versão ele vasculha todo seu histórico do git em busca de alguns vacilos como por exemplo uma chave que vc commitou e apagou, mas continua no histórico
4️⃣ Ele registra também o que tá CERTO.
Pra não bater a síndrome do impostor achando que tudo que vc faz tá errado, eu adicionei nele uma sessão que lista o que tá certo na sua condebase.
E pra fechar, ele gera um PDF lindão com todas as issues escritas em markdown, que você pode usar pra abrir uma issue no github ou então jogar no peito do seu agente.
🎯 Os 4 projetos que eu rodei
Achei os quatro em posts do r/brdev
1️⃣ Curió - app de notas, tarefas e lembretes em Flutter.
🔗 post no r/brdev · homi-lindo/curio (GPL-3.0)
2️⃣ Cofre Investimentos - carteira, cálculo de imposto de renda com importação do CSV da B3.
🔗 post no r/brdev · claudiorico/gestao-de-ativos-ai (MIT) · app no ar
3️⃣ Login com WhatsApp - um “entra com o WhatsApp” que você sobe na tua própria infra, em Docker, sem depender de Twilio nem de ninguém.
🔗 post no r/brdev · caiopizzol/whatsapp-web-api (MIT)
4️⃣ OpenBSP - o chefão, mais de 550 estrelas, roda em produção, atende cliente por WhatsApp e Instagram ligado direto na API da Meta.
🔗 post no r/brdev · matiasbattocchia/open-bsp-api · open-bsp-ui (Unlicense)
✅ EXTRA: O checklist antes de você fazer o deploy
Rodei o prompt e li o PDF inteiro, não só o resumo executivo
Todo endpoint que recebe um ID valida o dono antes de responder
Toda listagem/busca/exportação filtra pelo usuário ou tenant logado
Toda permissão que o frontend esconde, o servidor confere de novo
Nenhum segredo no código, no bundle do front, no
docker-composeou no CIRodei a busca no histórico do Git e revoguei o que apareceu, não só apaguei
Todo input do usuário é validado e sanitizado antes de virar HTML
Se é Supabase: RLS ligado em toda tabela e
service_rolefora do frontendOs achados viraram issue (endurecimento) ou advisory privado (explorável)
📡 E se você quer acompanhar a bolha de tecnologia sem romantização e sem papinho de vendedor de curso cola na live, quarta, 10 da manhã.
Tmj, forte abraço,
Mano Deyvin 🤙