// docs / baas security / clerk hardening

Llista de comprovació de seguretat de Clerk: 20 punts

Clerk gestiona l'autenticació, les sessions i les organitzacions de la teva aplicació — fet que vol dir que una integració de Clerk mal configurada és un bypass d'autenticació, un vector de fixació de sessió o una via de fuita d'organització. Aquesta llista de comprovació és una auditoria de 20 punts entre claus, configuració de sessió, webhooks, organitzacions, plantilles JWT i monitoratge continuat. Les eines de codificació amb IA configuren Clerk ràpidament amb valors per defecte sensats; aquesta llista captura els punts que deixen sense fer.

Per saber per què les configuracions errònies de la capa d'autenticació són un punt feble de les eines d'IA, consulta Per què les eines de codificació amb IA deixen mancances de seguretat. Per a la llista de comprovació paral·lela a Auth0, consulta Llista de comprovació de seguretat d'Auth0.

Claus d'entorn i llista d'orígens permesos

Clerk emet dues claus diferents per projecte. Barrejar-les o filtrar-les és el primer mode de fallida.

Fes servir la clau publicable (pk_live_* a producció, pk_test_* a desenvolupament) al navegador; fes servir la clau secreta (sk_live_* / sk_test_*) només al servidor. La clau publicable és segura a NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; la clau secreta no ha de portar mai un prefix d'env públic i no ha d'aparèixer mai en un component client.
Verifica que l'aplicació de producció fa servir pk_live_*, no pk_test_*. Les instàncies de prova permeten adreces d'email no verificades i MFA desactivada — enviar el mode test a producció és un bypass d'autenticació.
Configura els orígens permesos al panell de Clerk. Settings → Domains → Allowed origins ha de llistar exactament el teu domini de producció. Llistes d'orígens buides o amb comodí permeten als atacants crear frontends Clerk maliciosos que parlin amb el teu backend.
Rota la clau secreta a cada sortida o fuita sospitada. Panell → API Keys → Reset. La clau antiga queda invalidada; redesplega el codi del costat del servidor amb el nou valor abans de rotar.

Configuració de sessió

La caducitat de la sessió i els temps d'espera per inactivitat són la diferència entre que una sessió robada sigui un incident de 10 minuts o un de 30 dies.

Estableix el temps d'espera per inactivitat de la sessió a 30 minuts o menys per a aplicacions SaaS que manegin dades sensibles. Panell → Sessions → Inactivity timeout. Les aplicacions de nivell bancari haurien de fer servir 5-10 minuts; el SaaS estàndard 30-60 minuts; les aplicacions de consum 1-7 dies. El valor per defecte és 7 dies.
Habilita la revocació de sessió en canvis de contrasenya, canvis d'email i registre d'MFA. Panell → Sessions → Revoke on. Aquests són esdeveniments de seguretat iniciats per l'usuari; les sessions existents en altres dispositius s'haurien de matar.
Verifica les sessions al servidor en cada ruta protegida, no només a l'inici de sessió. A Next.js: const { userId } = await auth(); en un component servidor / ruta API llegeix el JWT de la cookie i el valida. No confiïs mai en una comprovació només de cookie.
Estableix SameSite=Lax (per defecte) o Strict a la cookie de sessió. Verifica-ho a DevTools → Application → Cookies. SameSite=None és un vector CSRF — no el facis servir mai tret que hagis configurat explícitament una autenticació entre dominis.

Verificació de webhooks

Els webhooks de Clerk es disparen en esdeveniments del cicle de vida d'usuari (created, updated, deleted, session.ended). Són el mecanisme de sincronització per a la teva base de dades — i un webhook falsificat és una primitiva d'escriptura a la base de dades.

Verifica la signatura Svix a cada webhook. Els webhooks de Clerk estan signats per Svix. Fes servir new Webhook(secret).verify(body, headers). Rebutja amb 401 si la verificació falla.
Emmagatzema el secret del webhook en una variable d'entorn, mai en codi. El secret es regenera a cada regeneració al panell — el teu desplegament l'ha de llegir d'env, no d'una constant.
Idempotència a cada handler. Les entregues de webhook es poden repetir. Fes servir la capçalera svix-id com a clau primària en una taula webhook_events per desduplicar. Embolcalla el canvi d'estat i la inserció d'idempotència a la mateixa transacció.
A user.deleted, esborra durament o anonimitza les PII en 24 hores. El RGPD / CCPA ho requereixen. Audita el camí d'eliminació: quines taules contenen les dades d'aquest usuari? Fes servir FK ON DELETE CASCADE on puguis.

Organitzacions i permisos

Si fas servir Clerk Organizations, la frontera d'organització és el teu aïllament de tenant. Cada consulta al servidor ha de filtrar per ella.

A cada ruta API, llegeix tant userId com orgId de auth() i filtra les consultes a la base de dades per tots dos. WHERE org_id = $orgId AND user_id = $userId. No confiïs mai en un org_id del cos de la petició.
<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.
Prova l'aïllament entre organitzacions amb dos comptes d'organització reals. Crea l'Organització A, omple-la de dades, inicia sessió a l'Organització B en un altre navegador, intenta llegir les dades de l'Organització A via l'API. La resposta ha de ser 403 o 404.

Plantilles JWT i integracions externes

Les plantilles JWT empenyen la identitat de Clerk cap a Supabase, Firebase i altres serveis descendents. Plantilles mal configurades comparteixen claims en excés o exposen dades que no volies.

Per a cada plantilla JWT, llista cada claim i confirma que és necessari. Panell → JWT Templates. Una plantilla que envia email i phone a Supabase exposa PII a qualsevol que llegeixi el JWT al navegador.
Estableix una caducitat curta a les plantilles JWT que es facin servir per a crides descendents del costat client. 60 segons per a sol·licituds API descendents és l'estàndard. Els JWT amb vida més llarga es roben i es repliquen.
Verifica el claim audience (aud) al costat receptor. Supabase, Firebase, etc. haurien de comprovar que aud coincideix amb l'identificador de servei esperat. Sense això, un JWT emès per al servei A pot autenticar-se al servei B.

Monitoratge operatiu

L'autenticació és la font de logs amb més senyal que tens. Vigila-la.

Alerta sobre pics d'inicis de sessió fallits per IP / per compte. Una taxa de fallades 50× la normal és un atac de credential stuffing. Clerk emet aquests esdeveniments als webhooks; encamina'ls al teu SIEM.
Revisió trimestral de la deriva de la configuració de sessió i instància. Els valors per defecte canvien a mesura que Clerk s'actualitza; les "configuracions antigues" es tornen incorrectes en silenci amb el temps. Compara l'exportació JSON del panell amb la teva última còpia coneguda bona.

Següents passos

Executa un escaneig de FixVibe contra el teu URL de producció — la comprovació baas.clerk-auth0 marca claus publicables de Clerk, claus de prova a producció i claus secretes en bundle. Per a la llista de comprovació equivalent a Auth0, consulta Llista de comprovació de seguretat d'Auth0. Per a la vista general entre proveïdors BaaS, llegeix Escàner de configuracions errònies de BaaS.