FixVibe

// docs / baas security / clerk hardening

Checklist de segurança Clerk: 20 itens

O Clerk gere auth, sessões e organizações para a sua app — o que significa que uma integração Clerk mal configurada é um bypass de auth, um vetor de fixação de sessão ou um caminho de vazamento entre orgs. Este checklist é uma auditoria de 20 itens através de chaves, configuração de sessão, webhooks, organizações, templates JWT e monitorização contínua. Ferramentas de codificação com IA fazem o cabeamento do Clerk rapidamente com padrões sensatos; esta lista apanha os itens que deixam na mesa.

Para contexto sobre porque é que configurações incorretas em nível de auth são um ponto fraco das ferramentas de IA, veja Porque é que ferramentas de codificação com IA deixam lacunas de segurança. Para o checklist paralelo no Auth0, veja Checklist de segurança Auth0.

Chaves de ambiente e allowlist de origem

O Clerk emite duas chaves distintas por projeto. Misturá-las ou vazá-las é o primeiro modo de falha.

  1. Use a chave publicável (pk_live_* em produção, pk_test_* em dev) no navegador; use a chave secreta (sk_live_* / sk_test_*) apenas no servidor. A chave publicável é segura em NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; a chave secreta nunca pode carregar um prefixo env público e nunca pode aparecer num componente cliente.
  2. Verifique que a app de produção usa pk_live_*, não pk_test_*. Instâncias de teste permitem endereços de e-mail não verificados e MFA desabilitado — publicar modo de teste em produção é um bypass de auth.
  3. Configure as origens permitidas no painel do Clerk. Settings → Domains → Allowed origins deve listar o seu domínio de produção exatamente. Listas de origens vazias ou com wildcard deixam atacantes criar frontends Clerk falsos que falam com o seu backend.
  4. Rotacione a chave secreta em qualquer saída ou vazamento suspeito. Painel → API Keys → Reset. Chave antiga é invalidada; republique o código do lado do servidor com o novo valor antes de rotacionar.

Configuração de sessão

Expiração de sessão e timeouts de inatividade são a diferença entre uma sessão roubada ser um incidente de 10 minutos ou de 30 dias.

  1. Defina timeout de inatividade de sessão em 30 minutos ou menos para apps SaaS que lidam com dados sensíveis. Painel → Sessions → Inactivity timeout. Apps de nível bancário devem usar 5-10 minutos; SaaS padrão 30-60 minutos; apps de consumo 1-7 dias. Padrão é 7 dias.
  2. Habilite revogação de sessão em mudança de palavra-passe, mudança de e-mail e inscrição em MFA. Painel → Sessions → Revoke on. São eventos de segurança iniciados pelo utilizador; sessões existentes noutros dispositivos devem ser eliminadas.
  3. Verifique sessões do lado do servidor em cada rota protegida, não apenas no sign-in. No Next.js: const { userId } = await auth(); num componente de servidor / rota de API lê o JWT do cookie e valida-o. Nunca confie numa verificação só de cookie.
  4. Defina SameSite=Lax (padrão) ou Strict no cookie de sessão. Verifique em DevTools → Application → Cookies. SameSite=None é um vetor CSRF — nunca use a menos que tenha explicitamente configurado uma auth entre domínios.

Verificação de webhooks

Webhooks do Clerk disparam em eventos de ciclo de vida de utilizador (criado, atualizado, eliminado, session.ended). São o mecanismo de sincronização para a sua base de dados — e um webhook forjado é uma primitiva de escrita em base de dados.

  1. Verifique a assinatura Svix em cada webhook. Webhooks do Clerk são assinados pelo Svix. Use new Webhook(secret).verify(body, headers). Rejeite com 401 se a verificação falhar.
  2. Armazene o segredo do webhook numa variável de ambiente, nunca no código. O segredo é rotacionado a cada regeneração no painel — o seu deploy deve lê-lo do env, não de uma constante.
  3. Idempotência em cada handler. Entregas de webhook podem repetir-se. Use o cabeçalho svix-id como chave primária numa tabela webhook_events para deduplicar. Envolva a mudança de estado e o insert de idempotência na mesma transação.
  4. Em user.deleted, elimine ou anonimize PII em 24 horas. RGPD / CCPA exigem. Audite o caminho de eliminação: que tabelas contêm os dados deste utilizador? Use FK ON DELETE CASCADE onde puder.

Organizações e permissões

Se usa Clerk Organizations, a fronteira de org é o seu isolamento de tenant. Cada consulta do lado do servidor deve filtrar por ela.

  1. Em cada rota de API, leia tanto userId quanto orgId de auth() e filtre consultas de base de dados por ambos. WHERE org_id = $orgId AND user_id = $userId. Nunca confie num org_id do corpo do pedido.
  2. <strong>Use Clerk role checks for privileged operations, not boolean checks against the user object.</strong> <code>has({ role: 'org:admin' })</code> reads the role from the verified JWT. A user can spoof a boolean on a stale client object; they cannot spoof a JWT claim.
  3. Teste isolamento entre orgs com duas contas de org reais. Crie Org A, popule dados, entre na Org B noutro navegador, tente ler os dados da Org A via API. A resposta deve ser 403 ou 404.

Templates JWT e integrações externas

Templates JWT empurram identidade Clerk para Supabase, Firebase e outros serviços downstream. Templates mal configurados partilham claims demais ou expõem dados que não queria.

  1. Para cada template JWT, liste cada claim e confirme que é necessário. Painel → JWT Templates. Um template que envia email e phone para o Supabase expõe PII a qualquer um que ler o JWT no navegador.
  2. Defina expiração curta em templates JWT usados para chamadas downstream do lado do cliente. 60 segundos para pedidos de API downstream é o padrão. JWTs de vida mais longa são roubados e reproduzidos.
  3. Verifique o claim de audiência (aud) no lado recetor. Supabase, Firebase, etc. devem verificar que aud corresponde ao identificador de serviço esperado. Sem isto, um JWT emitido para o serviço A pode autenticar-se ao serviço B.

Monitorização operacional

Auth é a fonte de logs de maior sinal que tem. Observe-a.

  1. Alerte em picos de logins falhos por IP / por conta. Uma taxa de falha 50× a normal é um ataque de credential stuffing. O Clerk emite estes eventos para webhooks; encaminhe para o seu SIEM.
  2. Revisão trimestral da deriva de configurações de sessão e instância. Padrões mudam à medida que o Clerk atualiza; "configurações antigas" tornam-se silenciosamente erradas com o tempo. Compare a exportação JSON do painel com a sua última cópia conhecida-boa.

Próximos passos

Execute um varrimento do FixVibe contra a sua URL de produção — a verificação baas.clerk-auth0 sinaliza chaves publicáveis do Clerk, chaves de teste em produção e chaves secretas no bundle. Para o checklist equivalente no Auth0, veja Checklist de segurança Auth0. Para a visão geral sobre fornecedores BaaS, leia Scanner de configurações incorretas de BaaS.

// varra a sua superfície baas

Encontre a tabela aberta antes que outra pessoa o faça.

Coloque uma URL de produção. O FixVibe enumera os fornecedores BaaS com que a sua app fala, identifica os seus endpoints públicos e reporta o que um cliente não autenticado pode ler ou escrever. Grátis, sem instalação, sem cartão.

  • Plano gratuito — 3 varrimentos/mês, sem cartão de registo.
  • Identificação BaaS passiva — sem necessidade de verificação de domínio.
  • Supabase, Firebase, Clerk, Auth0, Appwrite e mais.
  • Prompts de correção com IA em cada achado — cole de volta no Cursor / Claude Code.
Executar varrimento BaaS gratuito →

sem necessidade de registo

Checklist de segurança Clerk: 20 itens — Docs · FixVibe