---
name: security-audit
description: Auditoria profunda de seguranca com foco em vazamento de dados, tokens, secrets, autenticacao, autorizacao, API, frontend, dependencias, storage e compliance. 100+ checks em 12 categorias. Nota 0-100 + mapa de vulnerabilidades + plano de remediacao priorizado por severidade (CRITICAL/HIGH/MEDIUM/LOW).
---

# Security Audit — Auditoria de Seguranca Completa

## Quando ativar
- Quando o usuario digitar `/security-audit`
- Quando disser: "ta seguro?", "tem vazamento?", "token exposto?", "secrets?", "auditoria de seguranca", "dados vazando?", "LGPD?", "compliance?", "seguranca do projeto"

## Filosofia
Esta skill responde UMA pergunta: **"Se um hacker encontrar esse projeto, o que ele consegue explorar?"**

Pensar como atacante. Cada check e um vetor de ataque real. Nao e teoria — e o que pentester faz.

---

## EXECUCAO — 12 Categorias, 100+ Checks

### Passo 1: Identificar projeto e stack
```bash
cat package.json 2>/dev/null | head -10
cat CLAUDE.md 2>/dev/null | head -20
ls .env* .gitignore 2>/dev/null
```

### Passo 2: Rodar TODAS as categorias usando subagents em paralelo
- **Agent 1:** Categorias 1-3 (Secrets + Data Leakage + Auth)
- **Agent 2:** Categorias 4-6 (API + Frontend + Infra)
- **Agent 3:** Categorias 7-9 (Dependencies + Storage + Logging)
- **Agent 4:** Categorias 10-12 (WebSocket + Compliance + Git)

---

## CATEGORIA 1: SECRETS & TOKENS EXPOSTOS (15 pontos)

Esta e a categoria mais critica. Um secret exposto = acesso total.

| # | Check | Peso | Severidade | O que verificar |
|---|-------|------|-----------|----------------|
| 1.1 | Secrets hardcoded no codigo | 3 | CRITICAL | API keys, tokens, senhas literais no codigo fonte |
| 1.2 | .env no .gitignore | 2 | CRITICAL | .env, .env.local, .env.production DEVEM estar no .gitignore |
| 1.3 | .env exposto no build | 2 | CRITICAL | Vite/CRA prefixam VITE_/REACT_APP_ — qualquer env com esses prefixos vai pro bundle |
| 1.4 | Secrets no frontend | 3 | CRITICAL | API keys, tokens, secrets em arquivos .tsx/.jsx/.vue |
| 1.5 | JWT secret fraco | 1 | HIGH | Secret do JWT com menos de 32 chars ou valor previsivel |
| 1.6 | Chaves privadas no repo | 2 | CRITICAL | .pem, .key, .p12, .pfx no repositorio |
| 1.7 | .env.example com valores reais | 1 | HIGH | .env.example deve ter placeholders, NUNCA valores reais |
| 1.8 | Credentials em configs | 1 | HIGH | database URL com senha, SMTP com credenciais em config files |

**Como verificar cada um:**

```bash
# 1.1 — Secrets hardcoded (REGEX AMPLA)
grep -rn \
  "sk-[a-zA-Z0-9]\{20,\}\|sk_live_\|sk_test_\|pk_live_\|pk_test_\|ghp_\|gho_\|github_pat_\|glpat-\|xoxb-\|xoxp-\|AKIA[0-9A-Z]\{16\}\|AIza[0-9A-Za-z_-]\{35\}\|ya29\.\|Bearer [a-zA-Z0-9_-]\{20,\}" \
  src/ --include="*.ts" --include="*.tsx" --include="*.js" --include="*.jsx"

# 1.1b — Padroes de senha/key literal
grep -rni \
  "password\s*[:=]\s*[\"'][^\"']\{3,\}\|api.key\s*[:=]\s*[\"']\|secret\s*[:=]\s*[\"'][^\"']\{3,\}\|token\s*[:=]\s*[\"'][a-zA-Z0-9]\{10,\}" \
  src/ --include="*.ts" --include="*.tsx" \
  | grep -v "process\.env\|config\.\|\.env\|example\|placeholder\|TODO\|CHANGE_ME\|your_"

# 1.2 — .env no .gitignore
grep -c "\.env" .gitignore 2>/dev/null

# 1.3 — ENV vars que vazam pro frontend (Vite/CRA)
grep -rn "VITE_\|REACT_APP_" .env .env.production 2>/dev/null
# VERIFICAR: alguma dessas contem secret/key/token que NAO deveria ser publica?

# 1.4 — Secrets no frontend
grep -rni \
  "API_KEY\|API_SECRET\|PRIVATE_KEY\|SECRET_KEY\|ACCESS_TOKEN\|REFRESH_TOKEN\|CLIENT_SECRET\|DATABASE_URL\|SMTP_PASS\|AWS_SECRET" \
  src/ --include="*.tsx" --include="*.jsx" --include="*.vue"

# 1.5 — JWT secret fraco
grep -rn "jwt\|jsonwebtoken\|sign(\|verify(" src/ --include="*.ts" \
  | grep -i "secret\|key"
# Verificar: secret vem de process.env? Tem fallback hardcoded?

# 1.6 — Chaves privadas no repo
find . -name "*.pem" -o -name "*.key" -o -name "*.p12" -o -name "*.pfx" -o -name "*.jks" \
  | grep -v node_modules

# 1.7 — .env.example com valores reais
cat .env.example 2>/dev/null
# Verificar: tem valores que parecem reais (nao sao YOUR_KEY_HERE)?

# 1.8 — Credentials em configs
grep -rni "mongodb://.*:.*@\|postgres://.*:.*@\|mysql://.*:.*@\|smtp.*pass\|redis://.*:.*@" \
  . --include="*.ts" --include="*.json" --include="*.yml" --include="*.yaml" \
  | grep -v node_modules | grep -v ".env"
```

**VEREDICTO:** Se score < 10: "PARE TUDO. Secrets expostos. Rodar rotacao de credenciais ANTES de qualquer outra coisa."

---

## CATEGORIA 2: VAZAMENTO DE DADOS (10 pontos)

Dados que vazam sem o dev perceber — em respostas de API, logs, erros.

| # | Check | Peso | Severidade | O que verificar |
|---|-------|------|-----------|----------------|
| 2.1 | API retorna dados demais | 2 | HIGH | Endpoints retornando objetos inteiros do DB (SELECT * + send direto) |
| 2.2 | Senha em resposta de API | 2 | CRITICAL | Endpoint de user retorna campo password/hash |
| 2.3 | Stack trace em producao | 1 | HIGH | Erros expondo stack trace, paths internos, versoes |
| 2.4 | Dados sensiveis em URL | 1 | MEDIUM | Token, email, CPF em query string (cai em logs de servidor) |
| 2.5 | Autocomplete em campos sensiveis | 0.5 | LOW | Campos de senha/cartao sem autocomplete="off" |
| 2.6 | Dados em localStorage | 1 | MEDIUM | Token, dados pessoais no localStorage (acessivel por XSS) |
| 2.7 | Informacoes em headers | 1 | MEDIUM | X-Powered-By, Server header expondo tecnologia |
| 2.8 | Enumeracao de usuarios | 1 | HIGH | Login/reset diferencia "email nao existe" vs "senha errada" |
| 2.9 | IDOR — acesso a dados de outros | 0.5 | CRITICAL | Endpoints com /:id sem verificar se pertence ao usuario logado |

**Como verificar:**

```bash
# 2.1 — SELECT * sem filtro de campos
grep -rn "SELECT \*\|findAll()\|find({})\|\.all()" src/ --include="*.ts" \
  | grep -v "test\|spec\|migration"
# Depois verificar: o resultado e enviado direto pro res.json()?

# 2.2 — Password em response
grep -rn "password\|senha\|hash\|salt" src/ --include="*.ts" \
  | grep -i "json\|send\|response\|return\|res\."
# CRITICAL se password aparece em objeto retornado

# 2.3 — Stack trace em producao
grep -rn "stack\|err\.message\|error\.message\|JSON\.stringify.*err" src/ --include="*.ts"
# Verificar: error handler global filtra stack em producao?

# 2.4 — Dados sensiveis em URL
grep -rn "req\.query\.\|req\.params\." src/ --include="*.ts" \
  | grep -i "token\|email\|cpf\|password\|secret\|key"

# 2.6 — Dados em localStorage
grep -rn "localStorage\.\(setItem\|getItem\)" src/ --include="*.tsx" --include="*.ts"
# Verificar: o que e salvo? Token JWT = ok (preferivel httpOnly cookie). Dados pessoais = risco.

# 2.7 — Headers que expoe tecnologia
grep -rn "X-Powered-By\|app\.disable.*x-powered-by\|removeHeader\|helmet" src/ --include="*.ts"
# Express envia X-Powered-By: Express por padrao. Precisa desativar.

# 2.8 — Enumeracao de usuarios
grep -rn "not found\|nao encontr\|doesn't exist\|does not exist\|invalid email\|email invalido" \
  src/ --include="*.ts" | grep -i "login\|auth\|reset\|forgot"
# IDEAL: mesma mensagem pra email errado e senha errada

# 2.9 — IDOR
grep -rn "req\.params\.\(id\|userId\|user_id\)" src/ --include="*.ts"
# Verificar: cada endpoint que usa :id verifica se pertence ao req.user?
```

---

## CATEGORIA 3: AUTENTICACAO & AUTORIZACAO (10 pontos)

| # | Check | Peso | Severidade | O que verificar |
|---|-------|------|-----------|----------------|
| 3.1 | JWT com expiresIn | 1 | HIGH | Token sem expiracao = token eterno |
| 3.2 | Refresh token flow | 1 | HIGH | So access token curto (15min-1h) + refresh token longo |
| 3.3 | Token em httpOnly cookie | 1 | MEDIUM | Token em cookie httpOnly > localStorage (protege contra XSS) |
| 3.4 | Password hashing forte | 1 | CRITICAL | bcrypt/argon2/scrypt. NUNCA MD5/SHA1/SHA256 sem salt |
| 3.5 | Brute force no login | 1 | HIGH | Rate limit especifico no login (5-10 tentativas/min) |
| 3.6 | Logout invalida token | 1 | MEDIUM | Token blacklist ou short-lived + refresh |
| 3.7 | Rotas protegidas | 1 | CRITICAL | Todas as rotas que precisam de auth TEM middleware de auth |
| 3.8 | Role-based access | 1 | HIGH | Admin routes verificam role, nao so auth |
| 3.9 | Reset de senha seguro | 1 | HIGH | Token one-time com expiracao (1h max), nao envia senha por email |
| 3.10 | Session fixation | 1 | MEDIUM | Regenerar session/token apos login |

**Como verificar:**

```bash
# 3.1 — JWT sem expiracao
grep -rn "sign(\|jwt\.sign\|jsonwebtoken" src/ --include="*.ts"
# Verificar: tem expiresIn? Qual o valor? (ideal: 15min-1h access, 7-30d refresh)

# 3.2 — Refresh token
grep -rn "refresh\|refreshToken\|refresh_token" src/ --include="*.ts"
# Se nao existe: access token e o unico = se vazar, acesso permanente

# 3.3 — Cookie config
grep -rn "cookie\|httpOnly\|secure\|sameSite\|Set-Cookie" src/ --include="*.ts"
# Verificar: httpOnly: true, secure: true, sameSite: 'strict' ou 'lax'

# 3.4 — Password hashing
grep -rn "bcrypt\|argon2\|scrypt\|pbkdf2\|md5\|sha1\|sha256\|createHash" src/ --include="*.ts"
# CRITICAL se usa md5/sha1/sha256 sem salt pra senhas

# 3.5 — Rate limit no login
grep -rn "login\|signin\|sign-in" src/ --include="*.ts" | grep -i "limit\|throttle\|attempt"
# Verificar: tem rate limit ESPECIFICO pro endpoint de login?

# 3.7 — Rotas desprotegidas
# Passo 1: listar TODAS as rotas
grep -rn "router\.\(get\|post\|put\|delete\|patch\)\|app\.\(get\|post\|put\|delete\)" src/ --include="*.ts"
# Passo 2: verificar quais NAO tem middleware de auth
# Cada rota que modifica dados DEVE ter authenticate/authMiddleware/requireAuth

# 3.8 — Admin sem role check
grep -rn "admin\|/admin" src/ --include="*.ts"
# Verificar: rotas admin checam role == 'admin', nao so if (token)

# 3.9 — Reset de senha
grep -rn "reset\|forgot\|recover\|password" src/ --include="*.ts"
# Verificar: token one-time? expiracao? hash do token salvo no DB?
```

---

## CATEGORIA 4: SEGURANCA DE API (10 pontos)

| # | Check | Peso | Severidade | O que verificar |
|---|-------|------|-----------|----------------|
| 4.1 | Rate limiting global | 1 | HIGH | Middleware de rate limit em TODAS as rotas |
| 4.2 | Rate limiting por endpoint | 1 | HIGH | Endpoints criticos (login, signup, reset) com limits mais baixos |
| 4.3 | Input validation | 1 | HIGH | TODA entrada validada (Zod/Joi) antes de processar |
| 4.4 | SQL injection | 2 | CRITICAL | 100% prepared statements, ZERO concatenacao de string |
| 4.5 | NoSQL injection | 1 | CRITICAL | Se usa MongoDB: $gt, $ne, $regex sanitizados |
| 4.6 | Command injection | 1 | CRITICAL | Sem exec()/spawn() com input do usuario sem sanitizar |
| 4.7 | SSRF | 1 | HIGH | Se app faz fetch de URL externa: validar URL, bloquear internal IPs |
| 4.8 | Mass assignment | 1 | HIGH | req.body passado direto pro DB sem whitelist de campos |
| 4.9 | HTTP method tampering | 0.5 | MEDIUM | Rotas definem metodo especifico (nao app.all) |
| 4.10 | Request size limit | 0.5 | MEDIUM | Payload limit configurado (previne memory bomb) |

**Como verificar:**

```bash
# 4.1 — Rate limiting
grep -rn "rateLimit\|rate-limit\|express-rate-limit\|@fastify/rate-limit\|throttle" src/ --include="*.ts"
# Se nao existe: 0 pontos. Qualquer IP pode fazer 100k requests/s

# 4.4 — SQL injection
grep -rn "db\.\(prepare\|run\|get\|all\|exec\)" src/ --include="*.ts"
# Verificar CADA query:
# BOM: db.prepare("SELECT * FROM users WHERE id = ?").get(id)
# RUIM: db.exec(`SELECT * FROM users WHERE id = ${id}`)
# RUIM: db.prepare("SELECT * FROM users WHERE name = '" + name + "'")

# 4.6 — Command injection
grep -rn "exec(\|execSync\|spawn(\|spawnSync\|child_process\|shelljs" src/ --include="*.ts"
# Se input do usuario chega em exec(): CRITICAL
# Exemplo perigoso: exec(`ffmpeg -i ${userFile}`)

# 4.7 — SSRF
grep -rn "fetch(\|axios\.\(get\|post\)\|http\.get\|https\.get" src/ --include="*.ts"
# Se a URL vem do usuario: verificar se valida contra IPs internos (127.0.0.1, 10.x, 192.168.x, 169.254.x)

# 4.8 — Mass assignment
grep -rn "req\.body" src/ --include="*.ts"
# RUIM: db.run("INSERT INTO users VALUES (...)", ...Object.values(req.body))
# BOM: const { name, email } = req.body (destructure so o que precisa)
```

---

## CATEGORIA 5: SEGURANCA DO FRONTEND (10 pontos)

| # | Check | Peso | Severidade | O que verificar |
|---|-------|------|-----------|----------------|
| 5.1 | XSS — dangerouslySetInnerHTML | 2 | CRITICAL | Qualquer uso sem sanitizacao = XSS |
| 5.2 | XSS — innerHTML | 1 | CRITICAL | Mesmo que 5.1 mas fora do React |
| 5.3 | CSRF protection | 1 | HIGH | SameSite cookies OU CSRF token |
| 5.4 | Clickjacking — X-Frame-Options | 1 | MEDIUM | Header X-Frame-Options: DENY ou CSP frame-ancestors |
| 5.5 | CSP — Content Security Policy | 1 | HIGH | CSP header configurado pra bloquear scripts inline/externos |
| 5.6 | Open redirects | 1 | MEDIUM | Redirect baseado em parametro do usuario sem validacao |
| 5.7 | Dados sensiveis no source | 1 | HIGH | Comments com TODOs expondo logica, credenciais em comments |
| 5.8 | Source maps em producao | 1 | MEDIUM | .map files expostos = codigo fonte visivel |
| 5.9 | Subresource integrity | 0.5 | LOW | CDN scripts com integrity hash |
| 5.10 | Mixed content | 0.5 | MEDIUM | Recursos HTTP em pagina HTTPS |

**Como verificar:**

```bash
# 5.1 — XSS via React
grep -rn "dangerouslySetInnerHTML\|__html" src/ --include="*.tsx" --include="*.jsx"
# QUALQUER uso sem DOMPurify.sanitize() = CRITICAL

# 5.2 — innerHTML fora do React
grep -rn "innerHTML\|outerHTML\|document\.write\|insertAdjacentHTML" src/ --include="*.ts" --include="*.tsx"

# 5.3 — CSRF
grep -rn "csrf\|csurf\|sameSite\|SameSite\|_csrf\|csrfToken" src/ --include="*.ts"
# Se usa cookies pra auth e nao tem CSRF protection: HIGH

# 5.5 — CSP
grep -rn "Content-Security-Policy\|contentSecurityPolicy\|helmet.*csp\|csp(" src/ --include="*.ts"
# Sem CSP: scripts externos maliciosos podem rodar na pagina

# 5.6 — Open redirect
grep -rn "redirect\|window\.location\|location\.href\|res\.redirect" src/ --include="*.ts" --include="*.tsx"
# Se URL vem de req.query.returnUrl sem validacao: open redirect

# 5.8 — Source maps em producao
ls dist/**/*.map 2>/dev/null || ls build/**/*.map 2>/dev/null
# Se existem: codigo fonte completo visivel. Vite: sourcemap: false no vite.config.ts
grep -rn "sourcemap\|source.map\|devtool" vite.config.* webpack.config.* 2>/dev/null
```

---

## CATEGORIA 6: HEADERS DE SEGURANCA (8 pontos)

| # | Check | Peso | Severidade | O que verificar |
|---|-------|------|-----------|----------------|
| 6.1 | Helmet / security headers | 2 | HIGH | Helmet ou headers manuais configurados |
| 6.2 | X-Frame-Options | 1 | MEDIUM | DENY ou SAMEORIGIN |
| 6.3 | X-Content-Type-Options | 1 | MEDIUM | nosniff (previne MIME sniffing) |
| 6.4 | Strict-Transport-Security | 1 | HIGH | HSTS com max-age >= 31536000 |
| 6.5 | X-XSS-Protection | 0.5 | LOW | Deprecado mas nao custa |
| 6.6 | Referrer-Policy | 0.5 | MEDIUM | no-referrer ou strict-origin-when-cross-origin |
| 6.7 | Permissions-Policy | 1 | MEDIUM | Bloqueia camera, microfone, geolocation se nao usa |
| 6.8 | CORS configurado | 1 | HIGH | Origin especifico, nao "*" em producao |

**Como verificar:**

```bash
# 6.1 — Helmet
grep -rn "helmet\|app\.use.*helmet" src/ --include="*.ts"
# Se nao usa helmet: verificar headers manuais

# 6.8 — CORS
grep -rn "cors\|Access-Control-Allow-Origin" src/ --include="*.ts"
# RUIM: origin: "*" ou cors() sem config
# BOM: origin: "https://meusite.com.br"
# Verificar: em producao, origin e restrito ao dominio real?
```

---

## CATEGORIA 7: DEPENDENCIAS & SUPPLY CHAIN (7 pontos)

| # | Check | Peso | Severidade | O que verificar |
|---|-------|------|-----------|----------------|
| 7.1 | npm audit | 2 | HIGH | Vulnerabilidades conhecidas em dependencias |
| 7.2 | Dependencias desatualizadas | 1 | MEDIUM | Major versions atrasadas |
| 7.3 | Lock file | 1 | MEDIUM | package-lock.json ou pnpm-lock.yaml existe e esta no git |
| 7.4 | Dependencias nao usadas | 1 | LOW | Pacotes no package.json que ninguem importa |
| 7.5 | Typosquatting | 1 | HIGH | Nomes de pacotes suspeitos (ex: lodahs vs lodash) |
| 7.6 | Postinstall scripts | 1 | MEDIUM | Scripts que rodam no install podem ser maliciosos |

**Como verificar:**

```bash
# 7.1 — Vulnerabilidades conhecidas
npm audit 2>/dev/null || pnpm audit 2>/dev/null
# Contar: critical, high, moderate, low

# 7.2 — Desatualizadas
npm outdated 2>/dev/null || pnpm outdated 2>/dev/null

# 7.3 — Lock file
ls package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null
git ls-files package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null

# 7.6 — Postinstall scripts suspeitos
grep -A2 '"postinstall"\|"preinstall"\|"install"' node_modules/*/package.json 2>/dev/null | head -50
```

---

## CATEGORIA 8: FILE UPLOAD & STORAGE (5 pontos)

*Se o projeto nao faz upload de arquivos, redistribuir pontos.*

| # | Check | Peso | Severidade | O que verificar |
|---|-------|------|-----------|----------------|
| 8.1 | Validacao de tipo | 1 | CRITICAL | Verifica MIME type real, nao so extensao |
| 8.2 | Limite de tamanho | 1 | HIGH | maxFileSize configurado |
| 8.3 | Path traversal | 1 | CRITICAL | Nome do arquivo sanitizado (sem ../ ou /) |
| 8.4 | Diretorio de upload | 1 | HIGH | Fora do webroot, nao executavel |
| 8.5 | Virus scan | 1 | MEDIUM | ClamAV ou equivalente em uploads publicos |

**Como verificar:**

```bash
# Detectar se tem upload
grep -rn "multer\|formidable\|busboy\|multipart\|upload\|file.*upload" src/ --include="*.ts"

# 8.1 — Validacao de tipo
grep -rn "mimetype\|mime\|fileFilter\|allowedTypes\|accept" src/ --include="*.ts"
# RUIM: aceita qualquer tipo
# BOM: whitelist de MIME types (image/jpeg, image/png, application/pdf)

# 8.3 — Path traversal
grep -rn "originalname\|filename\|req\.file\|path\.join.*req\|path\.resolve.*req" src/ --include="*.ts"
# Verificar: nome do arquivo e sanitizado? Usa uuid/hash em vez do nome original?

# 8.4 — Diretorio de upload
grep -rn "dest:\|destination:\|uploadDir\|upload.*dir" src/ --include="*.ts"
# RUIM: dest: './public/uploads' (acessivel publicamente, executavel)
# BOM: dest: '/tmp/uploads' ou S3/cloud storage
```

---

## CATEGORIA 9: LOGGING & EXPOSICAO DE DADOS EM LOGS (5 pontos)

| # | Check | Peso | Severidade | O que verificar |
|---|-------|------|-----------|----------------|
| 9.1 | Senha em logs | 1 | CRITICAL | console.log(req.body) que inclui password |
| 9.2 | Token em logs | 1 | CRITICAL | Token JWT logado em texto plano |
| 9.3 | Dados pessoais em logs | 1 | HIGH | CPF, email, telefone em logs sem mascarar |
| 9.4 | Logs acessiveis publicamente | 1 | CRITICAL | Arquivo de log no webroot ou endpoint de log sem auth |
| 9.5 | Log injection | 1 | MEDIUM | Input do usuario em log sem sanitizar (permite forjar logs) |

**Como verificar:**

```bash
# 9.1 e 9.2 — Senha/token em logs
grep -rn "console\.log.*req\.body\|console\.log.*password\|console\.log.*token\|console\.log.*secret" \
  src/ --include="*.ts" --include="*.tsx"
# QUALQUER console.log que pode incluir senha/token = CRITICAL

# 9.1b — Log generico do body inteiro
grep -rn "console\.log.*body\|logger\.\(info\|debug\).*body\|log.*JSON\.stringify.*body" \
  src/ --include="*.ts"
# Se loga o body inteiro em rotas de login/signup/reset: CRITICAL

# 9.3 — Dados pessoais
grep -rn "console\.log.*email\|console\.log.*cpf\|console\.log.*phone\|console\.log.*celular" \
  src/ --include="*.ts"

# 9.4 — Logs acessiveis
ls public/logs/ 2>/dev/null
ls dist/logs/ 2>/dev/null
grep -rn "\.log\|/logs/" src/ --include="*.ts" | grep -i "static\|serve\|public"
```

---

## CATEGORIA 10: WEBSOCKET SECURITY (5 pontos)

*Se o projeto nao usa WebSocket, redistribuir pontos.*

| # | Check | Peso | Severidade | O que verificar |
|---|-------|------|-----------|----------------|
| 10.1 | Auth no handshake | 1 | CRITICAL | Conexao WS valida token antes de aceitar |
| 10.2 | Input validation em messages | 1 | HIGH | Mensagens WS validadas como qualquer input |
| 10.3 | Rate limit em messages | 1 | HIGH | Previne flood de mensagens |
| 10.4 | Broadcast autorizado | 1 | HIGH | Nao permite broadcast pra rooms de outros |
| 10.5 | Payload size limit | 1 | MEDIUM | maxPayload configurado |

**Como verificar:**

```bash
# 10.1 — Auth no WS
grep -rn "io\.use\|middleware.*socket\|handshake\|socket.*auth\|socket.*token" src/ --include="*.ts"
# Se nao tem: qualquer um conecta sem autenticar

# 10.2 — Validacao de mensagens
grep -rn "socket\.on(" src/ --include="*.ts"
# Verificar: cada handler valida o payload recebido?

# 10.3 — Rate limit WS
grep -rn "rateLimit.*socket\|socket.*throttle\|messageLimit\|floodControl" src/ --include="*.ts"

# 10.5 — Payload size
grep -rn "maxHttpBufferSize\|maxPayload" src/ --include="*.ts"
```

---

## CATEGORIA 11: GIT & REPOSITORIO (5 pontos)

| # | Check | Peso | Severidade | O que verificar |
|---|-------|------|-----------|----------------|
| 11.1 | .gitignore completo | 1 | HIGH | .env, node_modules, dist, *.log, .DS_Store |
| 11.2 | Secrets no historico git | 2 | CRITICAL | Mesmo se removido do codigo, ta no git history |
| 11.3 | .git exposto no servidor | 1 | CRITICAL | /.git/ acessivel via browser = codigo fonte completo |
| 11.4 | Branch protection | 1 | MEDIUM | main/master protegido contra push direto |

**Como verificar:**

```bash
# 11.1 — .gitignore
cat .gitignore 2>/dev/null
# DEVE conter: .env*, node_modules/, dist/, *.log, .DS_Store, *.pem, *.key

# 11.2 — Secrets no historico (CRITICO!)
git log --all --diff-filter=D -- "*.env" "*.pem" "*.key" 2>/dev/null
git log -p --all -S "sk-" -S "password" -S "secret" --since="1 year ago" -- "*.ts" "*.js" 2>/dev/null | head -50
# Se encontrar: secret JA VAZOU. Precisa ROTACIONAR, nao so deletar.

# 11.3 — .git exposto
# Verificar Nginx config: /.git deve retornar 403/404
grep -r "\.git" /etc/nginx/sites-available/ /etc/nginx/sites-enabled/ 2>/dev/null
```

---

## CATEGORIA 12: COMPLIANCE & PRIVACIDADE (5 pontos)

| # | Check | Peso | Severidade | O que verificar |
|---|-------|------|-----------|----------------|
| 12.1 | Dados pessoais criptografados | 1 | HIGH | CPF, cartao, dados sensiveis criptografados no DB |
| 12.2 | Consentimento (LGPD) | 1 | HIGH | Cookie consent, termos de uso aceitos antes de coletar |
| 12.3 | Direito de exclusao | 1 | MEDIUM | Mecanismo pra usuario deletar seus dados |
| 12.4 | Retencao de dados | 1 | MEDIUM | Politica de quanto tempo dados sao mantidos |
| 12.5 | Notificacao de breach | 1 | MEDIUM | Plano pra caso de vazamento (quem notificar, como) |

**Como verificar:**

```bash
# 12.1 — Criptografia de dados sensiveis
grep -rn "encrypt\|decrypt\|cipher\|aes\|AES\|crypto\.\(createCipher\|createDecipher\)" src/ --include="*.ts"
# Verificar: CPF, telefone, endereco sao criptografados no banco?

# 12.2 — Consentimento
grep -rn "consent\|cookie.*banner\|lgpd\|gdpr\|terms.*accept\|aceite\|consentimento" src/ --include="*.tsx" --include="*.ts"

# 12.3 — Delete account
grep -rn "delete.*account\|excluir.*conta\|deleteUser\|removeUser\|right.*erasure" src/ --include="*.ts"
```

---

## GERACAO DO RELATORIO

### Formato de saida:

```
SECURITY AUDIT — {Projeto}
===========================
Data: {YYYY-MM-DD}
Stack: {detectada}
Avaliador: Claude Code Security Audit v1.0

  ██████████░░░░░░░░░░  52/100  VULNERAVEL

  CATEGORIA                           SCORE    STATUS
  ──────────────────────────────────────────────────────
  1. Secrets & Tokens Expostos        8/15     RISCO
  2. Vazamento de Dados               6/10     ATENCAO
  3. Autenticacao & Autorizacao       5/10     RISCO
  4. Seguranca de API                 7/10     OK
  5. Seguranca do Frontend            4/10     RISCO
  6. Headers de Seguranca             3/8      CRITICO
  7. Dependencias & Supply Chain      5/7      OK
  8. File Upload & Storage            3/5      ATENCAO
  9. Logging & Exposicao em Logs      2/5      CRITICO
  10. WebSocket Security              4/5      OK
  11. Git & Repositorio               3/5      ATENCAO
  12. Compliance & Privacidade        2/5      RISCO

  ──────────────────────────────────────────────────────

  VULNERABILIDADES CRITICAL (explorar = acesso total):
  ──────────────────────────────────────────────────────
  1. [1.4] API key do Gemini hardcoded em src/services/ai.ts:12
     RISCO: Qualquer pessoa com acesso ao repo usa sua API key
     FIX: Mover pra .env → GEMINI_API_KEY=xxx → process.env.GEMINI_API_KEY

  2. [2.2] Endpoint GET /api/users/:id retorna password hash
     RISCO: Atacante com qualquer token ve hashes de senha
     FIX: Excluir campo password do SELECT ou do response

  3. [4.4] SQL injection em src/routes/search.ts:45
     RISCO: Acesso total ao banco de dados
     FIX: Trocar db.exec(`...${query}...`) por db.prepare("...?").all(query)

  VULNERABILIDADES HIGH (explorar = dano significativo):
  ──────────────────────────────────────────────────────
  4. [3.5] Login sem rate limit
     RISCO: Brute force descobre senha em minutos
     FIX: express-rate-limit no endpoint de login (5 req/min)

  5. [6.8] CORS com origin: "*"
     RISCO: Qualquer site faz requests autenticados
     FIX: origin: "https://seudominio.com.br"

  VULNERABILIDADES MEDIUM (explorar = informacao exposta):
  ──────────────────────────────────────────────────────
  6. [2.6] Token JWT no localStorage
  7. [5.8] Source maps em producao
  8. [2.7] X-Powered-By: Express exposto

  VULNERABILIDADES LOW (boas praticas):
  ──────────────────────────────────────
  9. [2.5] Campos de senha sem autocomplete="off"
  10. [7.4] 3 dependencias nao usadas

  ──────────────────────────────────────────────────────

  PLANO DE REMEDIACAO (por prioridade):
  ──────────────────────────────────────

  IMEDIATO (fazer AGORA — cada minuto exposto e risco):
    □ Rotacionar API key do Gemini (gerar nova, invalidar atual)
    □ Remover password hash do endpoint de user
    □ Corrigir SQL injection em search.ts

  URGENTE (fazer HOJE):
    □ Adicionar rate limit no login
    □ Restringir CORS
    □ Instalar e configurar Helmet
    □ Remover console.log que expoe body com senha

  ESTA SEMANA:
    □ Migrar token pra httpOnly cookie
    □ Desativar source maps em producao
    □ Configurar CSP header
    □ Rodar npm audit fix

  QUANDO PUDER:
    □ Criptografar dados pessoais no DB
    □ Implementar cookie consent (LGPD)
    □ Adicionar mecanismo de exclusao de conta
    □ Limpar dependencias nao usadas
```

### Classificacao final:

| Score | Status | Significado |
|-------|--------|-------------|
| 90-100 | BLINDADO | Seguranca solida. Manter e monitorar. |
| 75-89 | SEGURO | Bom, com pontos a polir. Nenhum critical. |
| 60-74 | ATENCAO | Tem vulnerabilidades. Corrigir antes de expor publicamente. |
| 40-59 | VULNERAVEL | Atacante intermediario consegue explorar. Urgente. |
| 0-39 | EXPOSTO | Atacante iniciante consegue explorar. PARAR e corrigir. |

### Salvar relatorio:

Salvar em `~/.claude/shield/reports/{projeto}-security-{data}.json`:
```json
{
  "project": "nome",
  "date": "2026-04-04",
  "score": 52,
  "status": "VULNERAVEL",
  "vulnerabilities": {
    "critical": [...],
    "high": [...],
    "medium": [...],
    "low": [...]
  },
  "categories": {...},
  "remediation_plan": {...}
}
```

---

## REGRAS DE EXECUCAO

1. **NUNCA inventar vulnerabilidade** — so reportar o que ENCONTROU com arquivo:linha
2. **SEMPRE dar o FIX exato** — nao so "corrija isso", dar o codigo/comando
3. **CRITICAL primeiro** — listar por severidade, nao por categoria
4. **Pensar como atacante** — "o que EU faria com esse acesso?"
5. **Considerar contexto** — app interno de mentoria != SaaS publico, mas AMBOS precisam de seguranca
6. **Secrets encontrados = rotacionar IMEDIATAMENTE** — nao basta deletar do codigo
7. **Git history conta** — secret que ja foi commitado JA VAZOU, mesmo se removido depois

## Integracao com Shield
- Complementa /scanner (que foca em codigo quebrado) e /scale-audit (que foca em escala)
- Alimenta /health-score com dados de seguranca
- Respeita Guardian — NUNCA remove funcionalidade, so ADICIONA seguranca
- Se encontrar CRITICAL: recomendar parar desenvolvimento e corrigir ANTES de continuar
