FixVibe

// docs / baas security / clerk hardening

Lista de comprobación de seguranza de Clerk: 20 elementos

Clerk encárgase da autenticación, as sesións e as organizacións para a túa aplicación — o que significa que unha integración de Clerk mal configurada é un bypass de autenticación, un vector de fixación de sesión ou un camiño de fuga entre organizacións. Esta lista é unha auditoría de 20 elementos en claves, configuración de sesión, webhooks, organizacións, plantillas JWT e monitorización continua. As ferramentas de codificación con IA conectan Clerk rapidamente con valores predeterminados sensatos; esta lista captura os elementos que deixan na mesa.

Para o fondo sobre por que as configuracións incorrectas a nivel de autenticación son un punto débil das ferramentas de IA, mira Por que as ferramentas de codificación con IA deixan fendas de seguranza. Para a lista paralela en Auth0, mira Lista de comprobación de seguranza de Auth0.

Claves de contorno e lista de orixes permitidas

Clerk emite dúas claves distintas por proxecto. Mesturalas ou filtralas é o primeiro modo de fallo.

  1. Usa a clave publicábel (pk_live_* en produción, pk_test_* en desenvolvemento) no navegador; usa a clave secreta (sk_live_* / sk_test_*) só no servidor. A clave publicábel é segura en NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; a clave secreta nunca debe levar un prefixo de contorno público e nunca debe aparecer nun compoñente cliente.
  2. Verifica que a aplicación de produción usa pk_live_*, non pk_test_*. As instancias de proba permiten enderezos de correo electrónico non verificados e MFA desactivado — enviar o modo de proba a produción é un bypass de autenticación.
  3. Configura as orixes permitidas no Panel de Clerk. Configuración → Dominios → Orixes permitidas debe listar o teu dominio de produción exactamente. Listas de orixes baleiras ou comodín permiten que os atacantes creen frontends Clerk falsos que falan co teu backend.
  4. Rota a clave secreta en calquera marcha ou sospeita de fuga. Panel → Claves API → Restablecer. A clave antiga inválidase; redesprega o código do servidor co novo valor antes de rotar.

Configuración de sesión

A expiración de sesión e os tempos de inactividade son a diferenza entre unha sesión roubada que é un incidente de 10 minutos e un de 30 días.

  1. Pon o tempo de inactividade de sesión a 30 minutos ou menos para aplicacións SaaS que xestionan datos sensibles. Panel → Sesións → Tempo de inactividade. As aplicacións de banca deberían usar 5-10 minutos; SaaS estándar 30-60 minutos; aplicacións de consumidor 1-7 días. O predeterminado é 7 días.
  2. Activa a revogación de sesión ao cambiar contrasinal, cambiar correo electrónico e activar MFA. Panel → Sesións → Revogar ao. Estes son eventos de seguranza iniciados polo usuario; as sesións existentes noutros dispositivos deben matarse.
  3. Verifica as sesións no servidor en cada ruta protexida, non só ao iniciar sesión. En Next.js: const { userId } = await auth(); nun compoñente do servidor / ruta API le o JWT da cookie e valídao. Nunca confíes nunha comprobación só de cookie.
  4. Pon SameSite=Lax (predeterminado) ou Strict na cookie de sesión. Verifica en DevTools → Aplicación → Cookies. SameSite=None é un vector CSRF — nunca o uses a menos que configurases explicitamente unha configuración de autenticación entre dominios.

Verificación de webhooks

Os webhooks de Clerk dispáranse en eventos do ciclo de vida do usuario (creado, actualizado, eliminado, session.ended). Son o mecanismo de sincronización para a túa base de datos — e un webhook falsificado é unha primitiva de escritura na base de datos.

  1. Verifica a sinatura de Svix en cada webhook. Os webhooks de Clerk están asinados por Svix. Usa new Webhook(secret).verify(body, headers). Rexeita con 401 se a verificación falla.
  2. Almacena o segredo do webhook nunha variable de contorno, nunca no código. O segredo rota en cada rexeración do Panel — o teu despregamento debe leelo do contorno, non dunha constante.
  3. Idempotencia en cada manexador. As entregas de webhook poden repetirse. Usa a cabeceira svix-id como clave primaria nunha táboa webhook_events para deduplicar. Envolve o cambio de estado e a inserción de idempotencia na mesma transacción.
  4. En user.deleted, elimina ou anonimiza PII en 24 horas. O RXPD / CCPA esíxeno. Audita o camiño de eliminación: que táboas conteñen os datos deste usuario? Usa FK ON DELETE CASCADE onde poidas.

Organizacións e permisos

Se usas Organizacións de Clerk, a fronteira da organización é o teu illamento de tenant. Cada consulta no servidor debe filtrar por ela.

  1. En cada ruta API, le tanto userId como orgId de auth() e filtra as consultas á base de datos por ambos. WHERE org_id = $orgId AND user_id = $userId. Nunca confíes nun org_id do corpo da solicitude.
  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. Proba o illamento entre organizacións con dúas contas de organización reais. Crea a Organización A, popula datos, inicia sesión na Organización B noutro navegador, intenta ler os datos da Organización A vía a API. A resposta debe ser 403 ou 404.

Plantillas JWT e integracións externas

As plantillas JWT empurran a identidade de Clerk a Supabase, Firebase e outros servizos descendentes. Plantillas mal configuradas comparten claims de máis ou expoñen datos que non querías expoñer.

  1. Para cada plantilla JWT, lista cada claim e confirma que é necesario. Panel → Plantillas JWT. Unha plantilla que envía email e phone a Supabase expón PII a calquera que lea o JWT no navegador.
  2. Pon expiración curta nas plantillas JWT usadas para chamadas descendentes do lado do cliente. 60 segundos para solicitudes API descendentes é o estándar. Os JWTs de vida máis longa son roubados e reproducidos.
  3. Verifica o claim de audiencia (aud) no lado receptor. Supabase, Firebase, etc. deben comprobar que aud coincide co identificador de servizo esperado. Sen isto, un JWT emitido para o servizo A pode autenticarse no servizo B.

Monitorización operacional

A autenticación é a fonte de rexistro de máis alta sinal que tes. Vixíaa.

  1. Alerta sobre picos de inicio de sesión fallidos por IP / por conta. Unha taxa de fallo 50× a normal é un ataque de credential stuffing. Clerk emite estes eventos a webhooks; encamíñaos ao teu SIEM.
  2. Revisión trimestral da desviación da configuración da sesión e a instancia. Os predeterminados cambian a medida que Clerk se actualiza; "as configuracións antigas" convértense silenciosamente en erradas co tempo. Compara a exportación JSON do Panel coa túa última copia coñecida-boa.

Próximos pasos

Executa un escaneo de FixVibe contra o teu URL de produción — a comprobación baas.clerk-auth0 sinala claves publicábeis de Clerk, claves de proba en produción e claves secretas no bundle. Para a lista equivalente en Auth0, mira Lista de comprobación de seguranza de Auth0. Para a visión global de provedores BaaS, le Escáner de configuración incorrecta de BaaS.

// escanea a túa superficie baas

Atopa a táboa aberta antes de que outra persoa o faga.

Introduce un URL de produción. FixVibe enumera os provedores de BaaS cos que fala a túa aplicación, identifica os seus endpoints públicos e informa do que un cliente non autenticado pode ler ou escribir. Gratis, sen instalación, sen tarxeta.

  • Plan gratuíto — 3 escaneos ao mes, sen tarxeta de rexistro.
  • Identificación pasiva de BaaS — non se require verificación de dominio.
  • Supabase, Firebase, Clerk, Auth0, Appwrite e máis.
  • Prompts de corrección con IA en cada achado — pégaos de volta en Cursor / Claude Code.
Executa un escaneo BaaS gratuíto →

non require rexistro

Lista de comprobación de seguranza de Clerk: 20 elementos — Docs · FixVibe