FixVibe

// docs / baas security / clerk hardening

Lista di cuntrollu di sicurezza Clerk: 20 elementi

Clerk tratta auth, sessioni è urganizazioni per a to app — ciò chì significheghja chì una integrazione Clerk mal cunfigurata hè un bypass di auth, un vettore di fixazione di sessione, o un percorsu di perdita d'urganizazione. Sta lista di cuntrollu hè un audit di 20 elementi trà chjavi, cunfigurazione di sessione, webhook, urganizazioni, mudelli JWT, è monitoraghju cuntinuu. L'attrezzi di codifica IA cullegheghjanu Clerk rapidamente cù difetti sensati; sta lista piglia l'elementi ch'elli lascianu sopra à u tavulu.

Per u sfondu nantu à perchè i sbagli di cunfigurazione di u stratu auth sò un puntu debule di l'attrezzi IA, vedi Perchè l'attrezzi di codifica IA lascianu falle di sicurezza. Per a lista di cuntrollu parallela nantu à Auth0, vedi Lista di cuntrollu di sicurezza Auth0.

Chjavi d'ambiente è lista d'urigini permesse

Clerk emette duie chjavi distinte per prughjettu. Mischjalle o perdele hè u primu modu di fallimentu.

  1. Adopra a chjave publishable (pk_live_* in produzzione, pk_test_* in sviluppu) in u navigatore; adopra a chjave secreta (sk_live_* / sk_test_*) solu nantu à u servitore. A chjave publishable hè sicura in NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; a chjave secreta ùn deve mai purtà un prefissu d'ambiente publicu è ùn deve mai apparisce in un cumpunente cliente.
  2. Verifica chì l'app di produzzione usa pk_live_*, micca pk_test_*. L'istanze di test permettenu indirizzi email micca verificati è MFA disattivatu — mandà test mode in produzzione hè un bypass di auth.
  3. Cunfigureghja l'urigini permesse in u Dashboard Clerk. Settings → Domains → Allowed origins deve listà u to duminiu di produzzione esattamente. Liste d'urigini viote o wildcard lascianu l'attaccanti creà frontend Clerk furfanti chì parlanu cù u to backend.
  4. Rutteghja a chjave secreta nantu à qualunque partenza o sospettu di perdita. Dashboard → API Keys → Reset. A vechja chjave hè invalidata; ri-spiega u codice latu servitore cù u novu valore prima di rutà.

Cunfigurazione di sessione

A scadenza di sessione è i timeout di inattività sò a sfarenza trà una sessione rubata chì hè un incidente di 10 minuti è unu di 30 ghjorni.

  1. Mette u timeout d'inattività di sessione à 30 minuti o menu per l'app SaaS chì trattanu dati sensibili. Dashboard → Sessions → Inactivity timeout. L'app di livellu bancariu duveranu aduprà 5-10 minuti; SaaS standard 30-60 minuti; app cunsumatore 1-7 ghjorni. U difettu hè 7 ghjorni.
  2. Attiva a revucazione di sessione nantu à cambiamentu di password, cambiamentu di email, è iscrizzione MFA. Dashboard → Sessions → Revoke on. Quessi sò eventi di sicurezza iniziati da l'utente; e sessioni esistenti nantu à altri dispusitivi duveranu esse ammazzate.
  3. Verifica e sessioni latu servitore in ogni rotta prutetta, micca solu à u sign-in. In Next.js: const { userId } = await auth(); in un cumpunente servitore / rotta API leghje u JWT da u cookie è u valideghja. Mai fidassi à un cuntrollu solu di cookie.
  4. Mette SameSite=Lax (difettu) o Strict nantu à u cookie di sessione. Verifica in DevTools → Application → Cookies. SameSite=None hè un vettore CSRF — mai aduprà lu salvu chì ùn hai cunfiguratu esplicitamente una cunfigurazione auth cross-duminiu.

Verifica di webhook

I webhook Clerk lancianu nantu à l'eventi di ciclu di vita d'utente (created, updated, deleted, session.ended). Sò u meccanismu di sincrunizazione per a to basa di dati — è un webhook fabbricatu hè una primitiva di scrittura di basa di dati.

  1. Verifica a firma Svix in ogni webhook. I webhook Clerk sò firmati da Svix. Adopra new Webhook(secret).verify(body, headers). Ricusa cù 401 s'è a verifica fallisce.
  2. Stocca u secretu di webhook in una variabile d'ambiente, mai in u codice. U secretu rutteghja in ogni rigenerazione di Dashboard — u to spiegamentu deve leghjelu da l'ambiente, micca da una custante.
  3. Idempotenza nantu à ogni handler. E cunsegne di webhook ponu ripetessi. Adopra l'header svix-id cum'è chjave primaria in una tabella webhook_events per deduplicà. Avvolge u cambiamentu di statu è l'inseriment d'idempotenza in listessa transazzione.
  4. Nantu à user.deleted, sguasseghja duramente o anonimisa PII in 24 ore. GDPR / CCPA u richiedenu. Auditeghja u percorsu di sguassatura: quali tabelle tenenu i dati di stu utente? Adopra FK ON DELETE CASCADE duve pudè.

Urganizazioni è permessi

S'è usi l'Urganizazioni Clerk, a fruntiera d'urganizazione hè a to isolazione di tenant. Ogni query latu servitore deve filtrà per ella.

  1. Nantu à ogni rotta API, leghji sia userId sia orgId da auth() è filtreghja e query di basa di dati per tramendue. WHERE org_id = $orgId AND user_id = $userId. Mai fidassi à un org_id da u corpu di a richiesta.
  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. Pruva l'isolazione cross-urganizazione cù dui cunti d'urganizazione veri. Crea Urganizazione A, pupula dati, iscriviti à Urganizazione B in un altru navigatore, prova à leghje i dati di l'Urganizazione A via l'API. A risposta deve esse 403 o 404.

Mudelli JWT è integrazioni esterne

I mudelli JWT spinghjenu l'identità Clerk in Supabase, Firebase, è altri servizii à valle. Mudelli mal cunfigurati cundividenu eccessivamente claim o espongenu dati chì ùn aviate intenzione di sparte.

  1. Per ogni mudellu JWT, lista ogni claim è cunferma ch'ellu hè necessariu. Dashboard → JWT Templates. Un mudellu chì manda email è phone à Supabase espone PII à chìunque leghje u JWT in u navigatore.
  2. Mette scadenza corta nantu à i mudelli JWT aduprati per chjamate à valle latu cliente. 60 secondi per richieste API à valle hè u standard. JWT cù vita più longa sò rubati è ripiglati.
  3. Verifica u claim audience (aud) nantu à u latu chì riceve. Supabase, Firebase, etc. devenu cuntrollà chì aud currisponde à l'identificatore di serviziu attesu. Senza questu, un JWT emessu per u serviziu A pò autenticà à u serviziu B.

Monitoraghju uperativu

Auth hè a fonte di log à più altu signale chì hai. Guardala.

  1. Allerta nantu à picchji di login falliti per IP / per cuntu. Una tassa di fallimentu 50× normale hè un attaccu di credential stuffing. Clerk emette sti eventi à webhook; instradeghjali à u to SIEM.
  2. Rivista trimestrale di driftu di paràmetri di sessione è istanza. I difetti cambianu quandu Clerk s'aghjorna; "vechje cunfigurazioni" diventanu in silenziu sbagliate cù u tempu. Diff l'esportu JSON di Dashboard contru à a to ultima cupia cunnisciuta cum'è bona.

Prussimi passi

Lampa una scansione FixVibe contru à u to URL di produzzione — u check baas.clerk-auth0 sgnala e chjavi publishable Clerk, e chjavi di test in produzzione, è e chjavi secrete impacchittate. Per a lista di cuntrollu equivalente nantu à Auth0, vedi Lista di cuntrollu di sicurezza Auth0. Per a vista d'imbrelli trà i fornitori BaaS, leghji Scanner di sbagli di cunfigurazione BaaS.

// scansiona a to superficia baas

Trova a tabella aperta prima chì qualcunu altru a faci.

Inserisci un URL di produzzione. FixVibe enumera i fornitori BaaS cù chì parla a to app, identifica i so endpoint pubblichi è riporta ciò chì un cliente micca autenticatu pò leghje o scrive. Gratisi, senza installazione, senza carta.

  • Pianu gratisi — 3 scansioni / mese, senza carta d'iscrizzione.
  • Fingerprinting BaaS passivu — nessuna verifica di duminiu richiesta.
  • Supabase, Firebase, Clerk, Auth0, Appwrite, è altri.
  • Suggerimenti di currezzione IA nantu à ogni risultatu — incollali in Cursor / Claude Code.
Lampa una scansione BaaS gratisa →

nisuna iscrizzione richiesta

Lista di cuntrollu di sicurezza Clerk: 20 elementi — Docs · FixVibe