// docs / baas security / clerk hardening

Lista de verificare pentru securitate Clerk: 20 de elemente

Clerk gestionează autentificarea, sesiunile și organizațiile pentru aplicația ta — ceea ce înseamnă că o integrare Clerk configurată greșit este un bypass de autentificare, un vector de fixare a sesiunii sau o cale de scurgere între organizații. Această listă de verificare este un audit cu 20 de elemente pe chei, configurare de sesiune, webhook-uri, organizații, șabloane JWT și monitorizare continuă. Instrumentele de codare AI configurează Clerk rapid cu setări implicite rezonabile; această listă detectează elementele pe care le lasă deoparte.

Pentru context despre de ce configurările greșite la stratul de autentificare sunt un punct slab al instrumentelor AI, vezi De ce instrumentele de codare AI lasă lacune de securitate. Pentru lista de verificare paralelă pe Auth0, vezi Lista de verificare pentru securitate Auth0.

Chei de mediu și allowlist de origini

Clerk emite două chei distincte pe proiect. Amestecarea lor sau scurgerea lor este primul mod de eșec.

Folosește cheia publicabilă (pk_live_* în producție, pk_test_* în dev) în browser; folosește cheia secretă (sk_live_* / sk_test_*) doar pe server. Cheia publicabilă este sigură în NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; cheia secretă nu trebuie să poarte niciodată un prefix env public și nu trebuie să apară niciodată într-un component client.
Verifică dacă aplicația de producție folosește pk_live_*, nu pk_test_*. Instanțele test permit adrese de email neverificate și MFA dezactivat — livrarea modului test în producție este un bypass de autentificare.
Configurează originile permise în Clerk Dashboard. Settings → Domains → Allowed origins trebuie să listeze exact domeniul tău de producție. Liste goale sau cu wildcard de origini le permit atacatorilor să creeze frontend-uri Clerk false care comunică cu backend-ul tău.
Rotește cheia secretă la orice plecare sau suspiciune de scurgere. Dashboard → API Keys → Reset. Cheia veche este invalidată; redeployează codul server cu noua valoare înainte de rotație.

Configurarea sesiunii

Expirarea sesiunii și timeout-urile de inactivitate sunt diferența dintre o sesiune furată fiind un incident de 10 minute și unul de 30 de zile.

Setează timeout-ul de inactivitate al sesiunii la 30 de minute sau mai puțin pentru aplicațiile SaaS care gestionează date sensibile. Dashboard → Sessions → Inactivity timeout. Aplicațiile de tip banking ar trebui să folosească 5-10 minute; SaaS standard 30-60 minute; aplicații consumer 1-7 zile. Implicit este 7 zile.
Activează revocarea sesiunii la schimbarea parolei, schimbarea email-ului și înregistrarea MFA. Dashboard → Sessions → Revoke on. Acestea sunt evenimente de securitate inițiate de utilizator; sesiunile existente pe alte dispozitive ar trebui omorâte.
Verifică sesiunile pe server pe fiecare rută protejată, nu doar la sign-in. În Next.js: const { userId } = await auth(); într-un server component / rută API citește JWT-ul din cookie și îl validează. Niciodată să nu te bazezi pe o verificare doar de cookie.
Setează SameSite=Lax (implicit) sau Strict pe cookie-ul de sesiune. Verifică în DevTools → Application → Cookies. SameSite=None este un vector CSRF — niciodată nu-l folosi decât dacă ai configurat explicit o configurație de autentificare cross-domain.

Verificarea webhook-urilor

Webhook-urile Clerk se declanșează la evenimente de ciclu de viață al utilizatorului (creat, actualizat, șters, sesiune încheiată). Sunt mecanismul de sincronizare pentru baza ta de date — și un webhook falsificat este o primitivă de scriere în bază.

Verifică semnătura Svix pe fiecare webhook. Webhook-urile Clerk sunt semnate de Svix. Folosește new Webhook(secret).verify(body, headers). Respinge cu 401 dacă verificarea eșuează.
Stochează secretul webhook-ului într-o variabilă de mediu, niciodată în cod. Secretul se rotește la fiecare regenerare în Dashboard — deploy-ul tău trebuie să-l citească din env, nu dintr-o constantă.
Idempotență pe fiecare handler. Livrările de webhook-uri se pot repeta. Folosește antetul svix-id ca cheie primară într-o tabelă webhook_events pentru dedupe. Înfășoară schimbarea de stare și inserția de idempotență în aceeași tranzacție.
La user.deleted, șterge definitiv sau anonimizează PII în 24 de ore. GDPR / CCPA o cer. Auditează calea de ștergere: ce tabele dețin datele acestui utilizator? Folosește FK ON DELETE CASCADE unde poți.

Organizații și permisiuni

Dacă folosești Clerk Organizations, granița organizației este izolarea ta de tenant. Fiecare interogare server-side trebuie să filtreze după ea.

Pe fiecare rută API, citește atât userId cât și orgId din auth() și filtrează interogările bazei de date după ambele. WHERE org_id = $orgId AND user_id = $userId. Niciodată să nu te bazezi pe un org_id din corpul cererii.
<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.
Testează izolarea între organizații cu două conturi reale de organizație. Creează Org A, populează date, conectează-te la Org B în alt browser, încearcă să citești datele Org A prin API. Răspunsul trebuie să fie 403 sau 404.

Șabloane JWT și integrări externe

Șabloanele JWT împing identitatea Clerk în Supabase, Firebase și alte servicii downstream. Șabloanele configurate greșit împart prea multe claim-uri sau expun date pe care nu ai vrut.

Pentru fiecare șablon JWT, listează fiecare claim și confirmă că este necesar. Dashboard → JWT Templates. Un șablon care livrează email și phone către Supabase expune PII oricui citește JWT-ul în browser.
Setează expirare scurtă pe șabloanele JWT folosite pentru apeluri downstream din partea clientului. 60 de secunde pentru cererile API downstream este standardul. JWT-urile cu durată mai lungă sunt furate și redate.
Verifică claim-ul audience (aud) pe partea de recepție. Supabase, Firebase etc. ar trebui să verifice că aud se potrivește cu identificatorul de serviciu așteptat. Fără asta, un JWT emis pentru serviciul A se poate autentifica la serviciul B.

Monitorizare operațională

Autentificarea este sursa de log-uri cu cel mai mare semnal pe care o ai. Urmărește-o.

Alertă la spike-uri de login-uri eșuate per IP / per cont. O rată de eșec de 50× normal este un atac de credential-stuffing. Clerk emite aceste evenimente către webhook-uri; rutează-le către SIEM-ul tău.
Revizuire trimestrială a deformării setărilor de sesiune și instanță. Setările implicite se schimbă pe măsură ce Clerk se actualizează; „configurațiile vechi" devin tăcut greșite în timp. Compară export-ul JSON al Dashboard-ului cu ultima ta copie cunoscută-bună.

Pași următori

Rulează o scanare FixVibe împotriva URL-ului tău de producție — verificarea baas.clerk-auth0 semnalează cheile publicabile Clerk, cheile test în producție și cheile secrete livrate în bundle. Pentru lista de verificare echivalentă pe Auth0, vezi Lista de verificare pentru securitate Auth0. Pentru perspectiva generală asupra furnizorilor BaaS, citește Scaner de configurări greșite BaaS.