wizz-method 1.8.0 → 1.9.0

package/package.json

@@ -1,7 +1,7 @@
 {
   "$schema": "https://json.schemastore.org/package.json",
   "name": "wizz-method",
-  "version": "1.8.0",
+  "version": "1.9.0",
   "description": "Wizz Method — método de agência orientado por IA em PT-BR (fork independente do BMad Method)",
   "keywords": [
     "agile",

package/src/modules/wizz/agents/wizz-qa/SKILL.md

@@ -25,6 +25,7 @@ Você é o QA do Wizz. Entra **depois do wizz-agent-dev**: pega o código pronto
 - Gerar testes E2E e rodar fluxos críticos → `wizz-qa-generate-e2e-tests`; para browser real, use `agent-browser`.
 - Revisão adversarial caçando bugs (assumir que tem bug) → `adversarial-reviewer`.
 - Revisão de qualidade/segurança do código → `wizz-code-review`; para segurança web profunda, use `web-security`.
+- Auditoria/pentest de segurança do app inteiro (varredura adversarial antes de release, "auditar segurança") → `security-audit-pentest` (caça com prova de exploração + plano priorizado). Para corrigir uma falha isolada, use `web-security`/`auth-and-secrets`.
 - Conferir se entrega o que foi pedido → comparo com o que o wizz-pm/usuário definiu.
 
 Sempre reporte achados em ordem de gravidade (crítico primeiro). Se passou em tudo, diga claramente que está pronto pra entregar.

package/src/skills-lib/auth-and-secrets/SKILL.md

@@ -42,6 +42,7 @@ Evita que um atacante descubra quais e-mails existem na base (login, signup, res
 - Auth gerenciada pelo Clerk: nunca reimplementar flows de auth manualmente
 - Toda rota protegida, Server Action e route handler chama `auth()` do Clerk no servidor. Nunca confiar em estado de sessão vindo do cliente
 - Clerk webhook (`svix`) verificado por assinatura antes de processar: não confiar no body sem verificar
+- Webhook de pagamento/provedor externo: além de verificar a assinatura, **nunca confie em valor de status, dinheiro ou permissão que veio no corpo**. Confirme com o provedor de origem (ex: re-buscar a sessão no Stripe pelo id) antes de liberar acesso ou creditar saldo. Assinatura válida só prova que o evento veio do provedor, não que o payload não foi remontado num replay.
 - Supabase RLS: toda tabela de domínio deve ter RLS ativo; queries devem filtrar por `workspace_id`/`user_id`
 - `SUPABASE_SERVICE_ROLE_KEY` bypassa RLS: só em server-side (API routes, jobs), nunca exposta no frontend
 - `NEXT_PUBLIC_*` = seguro expor no cliente; tudo sem `NEXT_PUBLIC_` = server-only

package/src/skills-lib/security-audit-pentest/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: security-audit-pentest
+description: >
+  Auditoria de segurança adversarial em 5 estágios com saída padronizada (tabela markdown, régua de corte,
+  payload concreto por achado). Use quando o pedido for auditar/pentestar um app inteiro, revisar segurança
+  antes de release, "auditoria de segurança", "pentest", "encontrar vulnerabilidades", ou rodar uma varredura
+  completa de mass assignment, IDOR/RLS, injeção, rate limit/abuso por volume, e vazamento por resposta.
+  Diferente de web-security/auth-and-secrets (que corrigem): esta CAÇA, com prova de exploração, e no fim funde
+  os achados num plano priorizado ("as três de hoje"). Use para revisão de correção de uma falha isolada as skills
+  web-security e auth-and-secrets.
+---
+
+# Security Audit (Pentest adversarial)
+
+Cinco estágios independentes de caça a vulnerabilidade, cada um com **prova de exploração concreta** e **régua de corte** (sem payload real, a linha não entra). No fim, um sexto passo funde os cinco relatórios num plano único priorizado.
+
+Cada estágio é um agente com um prompt fechado em `references/`. Rode-os em paralelo (subagentes), um por estágio, e depois o passo de fusão sobre os cinco resultados.
+
+## Premissa comum a todos os estágios
+
+Validação no cliente não conta. O atacante fala direto com a API. Considere apenas verificação no servidor. O campo "Como se explora" de cada achado tem que conter o **payload concreto** que o atacante enviaria, não a categoria da vulnerabilidade. "Poderia ser melhor" e "considere adicionar" não são achados. Prefira dez linhas reais a cinquenta de boa prática. Sem achado que passe na régua num estágio: responda só `NENHUM ACHADO NESTA ETAPA`.
+
+Formato de saída de cada estágio, tabela markdown, sem texto antes ou depois:
+
+```
+| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
+```
+
+Gravidade: CRÍTICO, ALTO, MÉDIO.
+
+## Os 5 estágios (rodar em paralelo)
+
+| Estágio | Caça | Prompt |
+|---|------|--------|
+| 1 | **Validação de entrada** — mass assignment (prioridade máxima), injeção SQL/NoSQL/shell, renderização insegura, schema ausente / texto sem limite | `references/stage-1-validacao-entrada.md` |
+| 2 | **Falha de autorização** — 3 camadas: app (identidade do cliente vs token; posse na query), banco (RLS, policy permissiva `USING(true)`, tabela nova sem policy), máquina (webhook sem assinatura, confia em status/dinheiro do body) | `references/stage-2-autorizacao.md` |
+| 3 | **Abuso por volume** — rate limit em auth (por IP **e** por conta), custo por chamada (IA/SMS/e-mail × 10k), extração por paginação, origem do IP atrás de proxy/CDN | `references/stage-3-abuso-volume.md` |
+| 4 | **Vazamento por resposta** — detalhe técnico em prod, divergência na auth (mensagem/status/tempo), existência de recurso (404 vs 403), secret em log | `references/stage-4-vazamento-resposta.md` |
+| 5 | **Fusão** — funde os 4 relatórios: dedup por origem cruzada, ordena por esforço÷gravidade, identifica cadeias, fecha com "as três de hoje" | `references/stage-5-fusao-plano.md` |
+
+> Estágios 1-4 são de caça e independentes. O estágio 5 recebe a saída dos outros quatro. (O prompt original tinha o estágio de validação duplicado; aqui é um só.)
+
+## Como rodar
+
+1. Dispare os estágios 1-4 como quatro subagentes em paralelo, cada um carregando seu prompt de `references/`.
+2. Colete as quatro tabelas.
+3. Rode o estágio 5 (fusão) colando as quatro tabelas onde o prompt indica.
+4. Entregue o plano de fusão como resultado. As tabelas por estágio ficam como anexo.
+
+## Relação com as outras skills de segurança
+
+- **Esta skill CAÇA** (encontra + prova). Saída = lista de achados + plano.
+- **`web-security` e `auth-and-secrets` CORRIGEM** (padrão certo + exemplo de código). Ao fechar um achado desta auditoria, abra a skill de correção correspondente citada na coluna "O que impede".

package/src/skills-lib/security-audit-pentest/references/stage-1-validacao-entrada.md

@@ -0,0 +1,50 @@
+# Estágio 1 — Validação de entrada
+
+Você é um analista de validação de entrada.
+
+Premissa: validação no cliente não conta. Um atacante fala
+direto com a API. Considere apenas verificação no servidor.
+
+Procure, nesta ordem de prioridade:
+
+1. ATRIBUIÇÃO EM MASSA — prioridade máxima
+   Todo endpoint de escrita onde o corpo da requisição é
+   repassado inteiro para o banco (spread do objeto, update
+   com o payload completo, create com todos os campos).
+   Para cada um: liste os campos da tabela que um atacante
+   conseguiria setar e que não estão no formulário.
+   Dê atenção especial a campos de papel, permissão, plano,
+   saldo, status de pagamento e id de dono.
+
+2. INJEÇÃO
+   Consultas montadas por concatenação ou template string
+   com valor vindo do usuário. Inclua SQL, NoSQL e comandos
+   de shell.
+
+3. RENDERIZAÇÃO INSEGURA
+   Conteúdo de usuário chegando em innerHTML,
+   dangerouslySetInnerHTML, v-html ou equivalente
+   sem sanitização no caminho.
+
+4. SCHEMA AUSENTE
+   Endpoints sem validação de tipo, formato ou tamanho.
+   Sinalize campos de texto sem limite máximo — são vetor
+   de exaustão de recurso.
+
+Para cada achado, o campo "Como se explora" deve conter
+o payload concreto que um atacante enviaria, não a categoria
+da vulnerabilidade.
+
+Formato de saída — tabela markdown, sem texto antes ou depois:
+
+| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
+
+Gravidade: CRÍTICO, ALTO, MÉDIO.
+
+REGRA DE CORTE: se você não conseguir preencher "Como se explora"
+com uma ação concreta e específica, NÃO inclua a linha.
+"Poderia ser melhor" não é achado. "Considere adicionar" não é achado.
+Prefiro dez linhas reais a cinquenta linhas de boa prática.
+
+Se não houver nenhum achado que passe nessa régua, responda
+apenas: NENHUM ACHADO NESTA ETAPA.

package/src/skills-lib/security-audit-pentest/references/stage-2-autorizacao.md

@@ -0,0 +1,61 @@
+# Estágio 2 — Falha de autorização
+
+Você é um pentester especializado em falha de autorização.
+
+Distinção que governa toda essa análise:
+AUTENTICAÇÃO responde "quem é você". AUTORIZAÇÃO responde
+"você pode acessar ISSO". Estar logado não é permissão.
+
+Analise as três camadas.
+
+CAMADA 1 — APLICAÇÃO
+Para cada endpoint que lê ou escreve um recurso pertencente
+a um usuário, responda:
+  a) De onde vem a identidade de QUEM está pedindo?
+     Do token/sessão no servidor, ou de algo enviado pelo cliente
+     (body, query, header, param)?
+  b) A consulta ao banco amarra o id do recurso E o dono
+     na mesma condição?
+Marque CRÍTICO todo lugar onde um user_id, org_id, tenant_id
+ou equivalente é lido do que o cliente enviou e usado para
+determinar propriedade.
+
+CAMADA 2 — BANCO
+Leia os arquivos de migration, schema e policy.
+  a) Liste as tabelas e diga, para cada uma, se há RLS
+     habilitada nos arquivos versionados.
+  b) Marque CRÍTICO toda policy permissiva —
+     USING (true), WITH CHECK (true) ou equivalente.
+     Uma policy permissiva é PIOR que policy nenhuma,
+     porque o painel mostra a trava como ativa.
+  c) Sinalize qualquer tabela criada em migration recente
+     que não tenha policy correspondente.
+
+CAMADA 3 — MÁQUINA
+Para cada webhook e endpoint que recebe evento externo:
+  a) Há validação de assinatura ou token compartilhado?
+  b) O fluxo confia em valor de status, dinheiro ou permissão
+     vindo no corpo, sem confirmar com o provedor de origem?
+
+LIMITE DA SUA ANÁLISE — obrigatório:
+Você está lendo arquivos. RLS de verdade é estado do banco,
+não arquivo. Termine com uma seção "NÃO VERIFICÁVEL AQUI"
+listando tudo que precisa ser confirmado no banco ao vivo
+ou no painel do provedor. Não afirme que está seguro
+o que você não conseguiu ver.
+
+Formato de saída — tabela markdown, sem texto antes ou depois:
+
+| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
+
+Gravidade: CRÍTICO, ALTO, MÉDIO.
+
+REGRA DE CORTE: se você não conseguir preencher "Como se explora"
+com uma ação concreta e específica, NÃO inclua a linha.
+"Poderia ser melhor" não é achado. "Considere adicionar" não é achado.
+Prefiro dez linhas reais a cinquenta linhas de boa prática.
+
+Se não houver nenhum achado que passe nessa régua, responda
+apenas: NENHUM ACHADO NESTA ETAPA.
+
+(Após a tabela, inclua a seção obrigatória "NÃO VERIFICÁVEL AQUI".)

package/src/skills-lib/security-audit-pentest/references/stage-3-abuso-volume.md

@@ -0,0 +1,49 @@
+# Estágio 3 — Abuso por volume
+
+Você é um analista de abuso por volume.
+
+Enumere TODA rota de entrada do sistema e classifique cada uma:
+TEM LIMITADOR / NÃO TEM LIMITADOR / NÃO DETERMINADO.
+
+Depois, marque as rotas nestas categorias:
+
+A) AUTENTICAÇÃO
+   Login, cadastro, recuperação de senha, verificação de código.
+   Sem limitador aqui significa força bruta e teste de
+   credenciais vazadas. Marque CRÍTICO.
+   Verifique também: o limitador conta por IP apenas, ou também
+   por conta alvo? Contagem só por IP é contornada distribuindo
+   o ataque.
+
+B) CUSTO POR CHAMADA
+   Rotas que gastam dinheiro real a cada execução:
+   chamada a modelo de linguagem, disparo de SMS, envio de e-mail,
+   processamento de arquivo, chamada a API paga de terceiro.
+   Para cada uma estime o custo unitário e o custo de
+   dez mil chamadas em loop.
+   Rota de agente de IA exposta sem limitador é CRÍTICO,
+   mesmo que não vaze nenhum dado.
+
+C) EXTRAÇÃO
+   Rotas que devolvem um registro por vez e que, chamadas em
+   sequência, entregam a base inteira.
+
+D) ORIGEM DO IP
+   Se o sistema roda atrás de proxy ou CDN, verifique de qual
+   cabeçalho o IP do cliente é lido. Se estiver lendo do
+   socket direto, o mundo inteiro conta como um IP só
+   e o limitador não existe na prática.
+
+Formato de saída — tabela markdown, sem texto antes ou depois:
+
+| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
+
+Gravidade: CRÍTICO, ALTO, MÉDIO.
+
+REGRA DE CORTE: se você não conseguir preencher "Como se explora"
+com uma ação concreta e específica, NÃO inclua a linha.
+"Poderia ser melhor" não é achado. "Considere adicionar" não é achado.
+Prefiro dez linhas reais a cinquenta linhas de boa prática.
+
+Se não houver nenhum achado que passe nessa régua, responda
+apenas: NENHUM ACHADO NESTA ETAPA.

package/src/skills-lib/security-audit-pentest/references/stage-4-vazamento-resposta.md

@@ -0,0 +1,52 @@
+# Estágio 4 — Vazamento por resposta
+
+Você é um analista de vazamento por resposta.
+
+Premissa: toda resposta de erro é informação. Você está
+procurando o que o sistema conta a quem falhou.
+
+1. DETALHE TÉCNICO EM PRODUÇÃO
+   Stack trace, caminho de arquivo do servidor, nome e versão
+   de framework ou biblioteca, fragmento de consulta SQL,
+   nome de tabela ou coluna chegando na resposta ao cliente.
+   Confirme se existe separação real entre comportamento de
+   desenvolvimento e de produção, ou se é o mesmo caminho.
+
+2. DIVERGÊNCIA NA AUTENTICAÇÃO — prioridade máxima
+   Compare as respostas de: e-mail inexistente, e-mail existente
+   com senha errada, e conta bloqueada.
+   Divergem em mensagem? Em código de status? Em campo do corpo?
+   E divergem em TEMPO de resposta, porque o caminho do e-mail
+   existente executa a verificação de hash e o outro não?
+   Qualquer divergência transforma o login numa API de consulta
+   da base de clientes. Marque CRÍTICO.
+   O mesmo vale para cadastro ("e-mail já em uso") e recuperação
+   de senha.
+
+3. EXISTÊNCIA DE RECURSO
+   Quando o usuário pede um recurso que existe mas não é dele,
+   a resposta é diferente de quando o recurso não existe?
+   Se for, dá para mapear os ids válidos contando respostas.
+   O correto é responder "não encontrado" nos dois casos.
+
+4. LOG
+   Senha, token, cabeçalho de autorização, dado de cartão ou
+   documento sendo gravado em log.
+
+Para cada achado, o campo "Como se explora" deve conter
+o payload concreto que um atacante enviaria, não a categoria
+da vulnerabilidade.
+
+Formato de saída — tabela markdown, sem texto antes ou depois:
+
+| # | Risco | Onde (arquivo:linha) | Como se explora | O que impede | Gravidade |
+
+Gravidade: CRÍTICO, ALTO, MÉDIO.
+
+REGRA DE CORTE: se você não conseguir preencher "Como se explora"
+com uma ação concreta e específica, NÃO inclua a linha.
+"Poderia ser melhor" não é achado. "Considere adicionar" não é achado.
+Prefiro dez linhas reais a cinquenta linhas de boa prática.
+
+Se não houver nenhum achado que passe nessa régua, responda
+apenas: NENHUM ACHADO NESTA ETAPA.

package/src/skills-lib/security-audit-pentest/references/stage-5-fusao-plano.md

@@ -0,0 +1,27 @@
+# Estágio 5 — Fusão num plano único
+
+Vou colar abaixo os relatórios das quatro etapas de auditoria
+(validação de entrada, autorização, abuso por volume, vazamento
+por resposta).
+
+Funda os quatro num plano único de correção:
+
+1. Remova duplicatas. O mesmo problema aparece em mais de uma
+   etapa com nomes diferentes — por exemplo, uma chave vazada
+   aparece no MAPA e o efeito dela aparece no ACESSO.
+   Trate como um item só, citando as duas origens.
+
+2. Reordene por ESFORÇO DE CORREÇÃO dividido por GRAVIDADE.
+   Primeiro o que é crítico e se resolve em minutos.
+   Por último o que é médio e exige refatoração.
+
+3. Identifique CADEIAS: onde dois achados de gravidade média
+   se combinam num caminho crítico. Exemplo: enumeração de
+   usuário no login mais ausência de limitador na mesma rota
+   é uma cadeia, e vale mais que a soma das partes.
+
+4. Termine com "AS TRÊS DE HOJE": os três itens que devem ser
+   corrigidos antes de qualquer outra coisa, com a justificativa
+   em uma linha cada.
+
+[colar os 4 relatórios abaixo]

package/src/skills-lib/web-security/SKILL.md

@@ -17,14 +17,21 @@ As que mais aparecem numa auditoria, com a correção direta. Use como triagem r
 |---|-------|-----------|----------|------|
 | 1 | SQL Injection | 🔴 Crítica (parada de linha) | Query parametrizada / query-builder, nunca interpolar string | `references/owasp-top5-detalhado.md` §3 |
 | 2 | IDOR (recurso por ID sem checar dono) | 🔴 Crítica (parada de linha) | Validar posse do recurso no servidor a cada request | `references/owasp-top5-detalhado.md` §1 |
-| 3 | Rate limit ausente (brute force grátis) | 🟠 Alta | Limite por IP **e** por conta + lockout/CAPTCHA no login | `references/headers-rate-limit-cors.md` |
-| 4 | CORS refletindo o `Origin` | 🟠 Alta | Allowlist de origens, nunca ecoar o `Origin` recebido | `references/headers-rate-limit-cors.md` |
-| 5 | PII/dado demais na resposta (até hash de senha) | 🟠 Alta | Retornar só os campos necessários (allowlist de saída) | `references/headers-rate-limit-cors.md` |
-| 6 | JWT na URL / token vivo pós-logout | 🟠 Alta | Token no header `Authorization` + revogar no logout | skill `auth-and-secrets` |
-| 7 | Enumeração de usuário (erro revela se e-mail existe) | 🟡 Média | Mensagem genérica + resposta em tempo constante | skill `auth-and-secrets` |
-| 8 | Clickjacking (sem header) | 🟡 Média (1 min) | `X-Frame-Options: DENY` + CSP `frame-ancestors 'none'` | `references/headers-rate-limit-cors.md` |
-
-> As duas primeiras (SQLi e IDOR) são **parada de linha**: apareceu, corrige antes de qualquer coisa.
+| 3 | Mass assignment (body inteiro vai pro banco) | 🔴 Crítica (parada de linha) | Allowlist de campos: só grave os campos do formulário, nunca `spread` do body | `references/owasp-top5-detalhado.md` §6 |
+| 4 | RLS permissiva (`USING(true)`) ou tabela sem policy | 🔴 Crítica | Policy que amarra `auth.uid()` ao dono; tabela nova sempre com policy | `references/owasp-top5-detalhado.md` §1 |
+| 5 | Rate limit ausente (brute force grátis) | 🟠 Alta | Limite por IP **e** por conta + lockout/CAPTCHA no login | `references/headers-rate-limit-cors.md` |
+| 6 | Origem do IP lida do socket atrás de CDN | 🟠 Alta | Ler IP do header certo (`x-forwarded-for` confiável do proxy), senão o rate limit não existe | `references/headers-rate-limit-cors.md` |
+| 7 | Custo por chamada sem limitador (IA/SMS/e-mail) | 🟠 Alta | Rate limit + quota por conta em toda rota que gasta dinheiro real | `references/headers-rate-limit-cors.md` |
+| 8 | Extração por paginação (base inteira registro a registro) | 🟠 Alta | Filtrar por dono na query + limite de página + detecção de varredura | `references/headers-rate-limit-cors.md` |
+| 9 | CORS refletindo o `Origin` | 🟠 Alta | Allowlist de origens, nunca ecoar o `Origin` recebido | `references/headers-rate-limit-cors.md` |
+| 10 | PII/dado demais na resposta (até hash de senha) | 🟠 Alta | Retornar só os campos necessários (allowlist de saída) | `references/headers-rate-limit-cors.md` |
+| 11 | JWT na URL / token vivo pós-logout | 🟠 Alta | Token no header `Authorization` + revogar no logout | skill `auth-and-secrets` |
+| 12 | Enumeração de usuário (erro revela se e-mail existe) | 🟡 Média | Mensagem genérica + resposta em tempo constante | skill `auth-and-secrets` |
+| 13 | Clickjacking (sem header) | 🟡 Média (1 min) | `X-Frame-Options: DENY` + CSP `frame-ancestors 'none'` | `references/headers-rate-limit-cors.md` |
+
+> As quatro primeiras (SQLi, IDOR, mass assignment e RLS permissiva) são **parada de linha**: apareceu, corrige antes de qualquer coisa.
+>
+> Para uma auditoria adversarial completa (caça com prova de exploração + plano priorizado), use a skill `security-audit-pentest`. Esta skill aqui é para **corrigir** uma falha específica da tabela.
 
 ## References (load on demand)
 

package/src/skills-lib/web-security/references/headers-rate-limit-cors.md

@@ -56,6 +56,17 @@ async headers() {
 - Comparações de token/secret: `crypto.timingSafeEqual`, nunca `!==` (detalhe em auth-and-secrets)
 - Sem rate limit = brute force de graça. Somar lockout/CAPTCHA após N falhas no login
 
+### Origem do IP atrás de proxy/CDN
+Se o app roda atrás de Vercel/Cloudflare/qualquer proxy, o IP do socket é o do proxy, não o do cliente. Ler o socket direto faz **o mundo inteiro contar como um IP só** e o rate limit deixa de existir na prática.
+- Vercel: use `x-forwarded-for` (ou `req.ip` no runtime que já resolve). Pegue o **primeiro** IP da lista, mas só confie na cadeia que vem do seu proxy.
+- Nunca confie em `x-forwarded-for` cru vindo de origem não-proxy (o cliente falsifica o header). Configure a lib de rate limit para o número certo de proxies à frente.
+
+### Custo por chamada (rota que gasta dinheiro real)
+Toda rota que chama modelo de linguagem, dispara SMS, envia e-mail, processa arquivo ou bate em API paga de terceiro precisa de rate limit **e** quota por conta. Rota de agente de IA exposta sem limitador é crítica mesmo sem vazar dado nenhum: 10.000 chamadas em loop viram conta de centenas a milhares de reais/dólares. Estime o custo unitário e multiplique por 10k ao avaliar a rota.
+
+### Extração por paginação
+Rota que devolve um registro por vez e, chamada em sequência, entrega a base inteira. Barre com: filtro por dono na query (o mesmo do IDOR), limite máximo de página, e detecção de varredura (muitos ids sequenciais do mesmo cliente).
+
 ## CORS
 - **Nunca reflita o header `Origin` recebido** de volta em `Access-Control-Allow-Origin` (isso libera qualquer site a chamar sua API com credenciais)
 - Use uma **allowlist explícita** de origens: compare o `Origin` recebido contra a lista e só então ecoe o valor exato daquela origem

package/src/skills-lib/web-security/references/owasp-top5-detalhado.md

@@ -28,6 +28,38 @@ export async function GET(req: Request, { params }: { params: Promise<{ id: stri
 }
 ```
 
+### RLS: policy permissiva é pior que policy nenhuma
+Ler os arquivos de migration/policy versionados e checar:
+- Toda tabela de domínio tem `ENABLE ROW LEVEL SECURITY`?
+- Nenhuma policy é permissiva: `USING (true)` ou `WITH CHECK (true)` libera geral, mas o painel do Supabase mostra a trava como "ativa". Amarre sempre ao dono: `USING (auth.uid() = user_id)`.
+- Tabela criada em migration recente **sem** policy correspondente = exposta.
+
+```sql
+-- ERRADO: mostra RLS ativo no painel, mas libera qualquer um
+create policy "read" on projects for select using (true);
+
+-- CERTO: amarra o dono
+alter table projects enable row level security;
+create policy "own rows" on projects
+  for select using (auth.uid() = user_id);
+```
+
+> RLS de verdade é estado do banco, não arquivo. O que está no repo é ponto de partida: confirme o estado real no dashboard/`\d+` do Postgres.
+
+## 6. Mass Assignment (atribuição em massa)
+O corpo da requisição inteiro repassado para o banco (`spread` do objeto, `update`/`create` com o payload completo) deixa o atacante setar qualquer coluna, mesmo as que não estão no formulário. Alvos clássicos: `role`, `is_admin`, `plan`, `balance`, `payment_status`, `user_id`/`owner_id`.
+
+```ts
+// ERRADO: o cliente manda { name: "x", role: "admin" } e vira admin
+await supabase.from("users").update({ ...body }).eq("id", userId)
+
+// CERTO: allowlist explícita, só os campos do formulário
+const { name, bio } = updateSchema.parse(body) // Zod com só os campos permitidos
+await supabase.from("users").update({ name, bio }).eq("id", userId)
+```
+
+Regra: **nunca** `...body` / `...req.body` num write. Sempre desestruture (ou valide com um schema que só contém os campos editáveis). Campos de papel, permissão, plano, saldo, status de pagamento e id de dono nunca vêm do cliente.
+
 ## 2. Cryptographic Failures
 - HTTPS em tudo, sem exceção
 - HSTS header com includeSubDomains

package/src/skills-lib/wizz-router/references/routing-table-flat.md

@@ -15,6 +15,7 @@ Use esta tabela **só fora de projeto Wizz** (sem `_wizz/`), quando o router map
 | Auth, secrets, tokens, OAuth, JWT, Clerk, permissões | `auth-and-secrets` + `web-security` | 1 |
 | Dependências, packages, vulnerabilidades, npm audit | `database-and-deps` | 2 |
 | Segurança, XSS, CSRF, SQLi, IDOR, OWASP, rate limit, CORS, clickjacking, PII na resposta, enumeração de usuário, headers | `web-security` + `auth-and-secrets` | 1 |
+| Auditoria/pentest de segurança do app inteiro, "auditar segurança", "pentest", "encontrar vulnerabilidades", varredura antes de release | `security-audit-pentest` | 1 |
 | Desktop, Electron, contextIsolation, code signing | `desktop-security` | 2 |
 
 ## Área Técnica — Código e Qualidade