📋 Relatório de Auditoria de Segurança - Webhooks e APIs

1.1.3 Webhooks e Autenticação

✅ ti-webhook-receiver/index.ts

⚠️ Risco Baixo: Query token pode vazar em logs/URLs (l. 169-176). Considerar deprecar.

✅ inss-webhook/index.ts

---

🔴 Edge Functions - APIs Externas

ERRO CRÍTICO: delete-google-calendar (l. 8) tem CORS aberto e não autentica nenhuma requisição. Qualquer site pode deletar eventos!

---

1.1.4 Rate Limiting

✅ _shared/rate-limit.ts (l. 1-58)

• Implementação: In-Memory Map (isolate-scoped)
• ✅ Headers X-RateLimit-* corretos
• ✅ Limite de janela: 60 segundos
• ⚠️ Limitação: Reseta em cold starts (sem persistência)

Uso por Function

---

📊 Resumo de Problemas

---

✅ Comandos de Verificação (Executados)

---

📋 Recomendações Prioritárias

1. IMEDIATO: Adicionar autenticação em delete-google-calendar e sync-google-calendar
2. URGENTE: Adicionar rate limiting em todas as functions do Google Calendar (chatam API externa)
3. IMPORTANTE: Unificar rate limiting para usar _shared/rate-limit.ts em todas
4. CONSIDERAR: Migrar para Redis-backed rate limiting para persistência cross-isolate

[thinking] Agora tenho todas as informações necessárias para fazer a auditoria completa. Vou compilar um relatório detalhado baseado nas boas práticas do Supabase que li no SKILL.md.

📋 Relatório de Auditoria de Segurança - Webhooks e Rate Limiting

1.1.3 Webhooks e Autenticação de APIs

✅ ti-webhook-receiver/index.ts (Linhas 1-369)

⚠️ Problemas Identificados:

1. Query token exposto em logs (l. 171-175) - O token pode vazar se o header X-Webhook-Signature ou Authorization não estiverem presentes (query params aparecem em URLs de logs)
2. Sem verificação de secret em cache: Se TI_WEBHOOK_SECRET estiver vazio, retorna erro imediato (l. 139-142) - OK
3. Nenhum método auth → 401 (l. 178-184) ✅ Comportamento correto

✅ Implementações Seguras:

• Raw body usado antes do parse para HMAC (l. 213-214)
• Log estruturado com método tentado (l. 219-225)
• Idempotency Key logado (l. 207-210)

---

✅ inss-webhook/index.ts (Linhas 1-288)

⚠️ Observações:

1. Sem timingSafeEqual custom - Usa Web Crypto API diretamente (recomendado e mais seguro)
2. Timeout 30s no Gemini (l. 176) - Adequado
3. CORS para OPTIONS (l. 37-39) - OK

✅ Segurança Excepcional:

• Fall-through da IA testado (try/catch em Gemini com fallback implícito)
• Logging estruturado de falhas de extração (l. 230-266)

---

🔍 Outros Webhooks Identificados:

Não há outros webhooks - As demais functions são APIs REST normais, não webhooks.

---

🔑 Edge Functions - APIs Externas:

⚠️ NOTA CRÍTICA - delete-google-calendar/index.ts (l. 1-63):

• Access-Control-Allow-Origin: * (l. 8) - ❌ CORS permissivo demais
• Sem JWT authentication - Apenas verifica GOOGLE_CALENDAR_ACCESS_TOKEN (l. 28-34)
• Vulnerável a CSRF - Qualquer site pode chamar

---

1.1.4 Rate Limiting

✅ supabase/functions/_shared/rate-limit.ts (Linhas 1-58)

⚠️ Limitações Documentadas (comentários):

• ✅ In-memory = reset em cada deploy/cold start
• ✅ Não compartilhado entre isolates (o Supabase Edge Functions roda em múltiplos isolados)

Uso por Function:

⚠️ Problemas:

1. Rate limit inconsistente: djen-bypass implementa seu próprio rate limit (l. 56-96) em vez de usar _shared/rate-limit.ts
2. Funções do Google Calendar sem rate limit: sync-google-calendar, delete-google-calendar (ambas usam GOOGLE_CALENDAR_ACCESS_TOKEN fixo!)
3. Sem Redis/backend: In-memory é suscetível a restart do Edge Runtime

---

📊 Resumo dos Problemas Críticos

---

✅ Comandos de Verificação (Executados)

# Listar todas as Edge Functions
ls supabase/functions/ | grep webhook  # 2 webhooks encontrados

# Buscar HMAC implementation  
# ✅ ti-webhook-receiver: verifyHMAC (l. 98)
# ✅ inss-webhook: verifyHMAC (l. 9)

# Buscar timing-safe comparison  
# ✅ ti-webhook-receiver: timingSafeEqual (l. 79)
# ✅ _shared/auth.ts: JWT verification com jose library

# Buscar rate limit
# ✅ 4 functions usando enforceRateLimit
# ⚠️ 2 functions sem rate limit (google-calendar-*)

# X-RateLimit headers
# ✅ todos que usam enforceRateLimit retornam headers corretos

Recomendação: Implementar rate limiting via Redis ou Supabase Rate Limiting service para