// docs / baas security / clerk hardening

Sigurnosna checklista za Clerk: 20 stavki

Clerk upravlja autentifikacijom, sesijama i organizacijama za vašu aplikaciju — što znači da je pogrešno konfigurisana Clerk integracija auth bypass, vektor za session fixation ili put curenja organizacija. Ova checklista je audit od 20 stavki koji pokriva ključeve, konfiguraciju sesija, webhookove, organizacije, JWT template i tekući monitoring. AI alati za kodiranje brzo žice Clerk s razumnim defaultima; ova lista hvata stavke koje ostavljaju neriješene.

Za pozadinu zašto su pogrešne konfiguracije na auth sloju slaba tačka AI alata, pogledajte Zašto AI alati za kodiranje ostavljaju sigurnosne propuste. Za paralelnu checklistu za Auth0, pogledajte Sigurnosnu checklistu za Auth0.

Environment ključevi i allowlist origina

Clerk izdaje dva različita ključa po projektu. Miješanje ili curenje je prvi način otkaza.

Koristite publishable ključ (pk_live_* u produkciji, pk_test_* u dev okruženju) u pregledniku; koristite tajni ključ (sk_live_* / sk_test_*) samo na serveru. Publishable ključ je siguran u NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; tajni ključ nikada ne smije imati javni env prefiks niti se ikada pojaviti u klijentskoj komponenti.
Provjerite da produkcijska aplikacija koristi pk_live_*, ne pk_test_*. Test instance dozvoljavaju neverificirane email adrese i onemogućen MFA — isporučivanje test moda u produkciju je auth bypass.
Konfigurišite dozvoljene origine u Clerk dashboardu. Settings → Domains → Allowed origins mora navoditi tačno vašu produkcijsku domenu. Prazna lista origina ili lista sa wildcardom dozvoljavaju napadačima da kreiraju lažne Clerk frontende koji razgovaraju s vašim backendom.
Rotirajte tajni ključ pri svakom odlasku ili sumnji na curenje. Dashboard → API Keys → Reset. Stari ključ se poništava; redeploy-ajte serverski kod s novom vrijednošću prije rotacije.

Konfiguracija sesija

Istek sesije i idle timeouti razlikuju je li ukradena sesija 10-minutni incident ili 30-dnevni.

Postavite session inactivity timeout na 30 minuta ili manje za SaaS aplikacije koje rukuju osjetljivim podacima. Dashboard → Sessions → Inactivity timeout. Aplikacije bankarskog nivoa trebaju koristiti 5-10 minuta; standardni SaaS 30-60 minuta; potrošačke aplikacije 1-7 dana. Default je 7 dana.
Omogućite poništavanje sesija pri promjeni lozinke, promjeni email-a i upisu MFA. Dashboard → Sessions → Revoke on. Ovo su sigurnosni događaji koje inicira korisnik; postojeće sesije na drugim uređajima trebaju biti ubijene.
Verificirajte sesije na serverskoj strani na svakoj zaštićenoj ruti, ne samo pri prijavi. U Next.js-u: const { userId } = await auth(); u serverskoj komponenti / API ruti čita JWT iz kolačića i validira ga. Nikada ne vjerujte samo provjeri kolačića.
Postavite SameSite=Lax (default) ili Strict na kolačić sesije. Provjerite u DevTools → Application → Cookies. SameSite=None je CSRF vektor — nikada ga ne koristite osim ako niste eksplicitno konfigurisali postavku cross-domain autentifikacije.

Verifikacija webhookova

Clerk webhookovi se aktiviraju na događajima životnog ciklusa korisnika (kreiran, ažuriran, obrisan, session.ended). Oni su mehanizam sinhronizacije za vašu bazu — a falsifikovan webhook je primitiva za pisanje u bazi.

Verifikujte Svix potpis na svakom webhooku. Clerk webhookovi su potpisani od strane Svix-a. Koristite new Webhook(secret).verify(body, headers). Odbijte sa 401 ako verifikacija ne uspije.
Čuvajte webhook tajnu u environment varijabli, nikad u kodu. Tajna rotira pri svakoj regeneraciji u dashboardu — vaš deploy mora je čitati iz env-a, ne iz konstante.
Idempotentnost na svakom handleru. Isporuke webhookova mogu se ponoviti. Koristite header svix-id kao primarni ključ u tabeli webhook_events za deduplikaciju. Omotajte promjenu stanja i insert za idempotentnost u istu transakciju.
Pri user.deleted, tvrdo obrišite ili anonimizirajte PII u roku od 24 sata. GDPR / CCPA to zahtijevaju. Auditujte putanju brisanja: koje tabele drže podatke ovog korisnika? Koristite FK ON DELETE CASCADE gdje možete.

Organizacije i dozvole

Ako koristite Clerk organizacije, granica organizacije je vaša izolacija najmova. Svaki serverski upit mora filtrirati po njoj.

Na svakoj API ruti, pročitajte i userId i orgId iz auth() i filtrirajte database upite po oba. WHERE org_id = $orgId AND user_id = $userId. Nikada ne vjerujte org_id iz tijela zahtjeva.
<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.
Testirajte cross-org izolaciju s dva stvarna org računa. Kreirajte organizaciju A, popunite podacima, prijavite se u organizaciju B u drugom pregledniku, pokušajte čitati podatke organizacije A preko API-ja. Odgovor mora biti 403 ili 404.

JWT template i eksterne integracije

JWT template guraju Clerk identitet u Supabase, Firebase i druge nizvodne servise. Pogrešno konfigurisani template prekomjerno dijele claimove ili izlažu podatke koje niste namjeravali.

Za svaki JWT template, navedite svaki claim i potvrdite da je neophodan. Dashboard → JWT Templates. Template koji šalje email i phone u Supabase izlaže PII svakome ko čita JWT u pregledniku.
Postavite kratak istek na JWT template korišten za klijentske nizvodne pozive. 60 sekundi za nizvodne API zahtjeve je standard. Dugotrajniji JWT-ovi se kradu i reproduciraju.
Verifikujte audience (aud) claim na primajućoj strani. Supabase, Firebase, itd. trebaju provjeriti da aud odgovara očekivanom identifikatoru servisa. Bez ovoga, JWT izdat za servis A može se autentifikovati prema servisu B.

Operativni monitoring

Auth je izvor logova s najvišim signalom koji imate. Pazite na to.

Upozorenje na skokove neuspjelih prijava po IP-u / po računu. 50× normalna stopa neuspjeha je credential stuffing napad. Clerk emituje ove događaje na webhookove; rutirajte ih u svoj SIEM.
Kvartalni pregled drifta u postavkama sesija i instance. Defaulti se mijenjaju kako se Clerk ažurira; "stare konfiguracije" vremenom tiho postaju pogrešne. Diff-ujte JSON export iz dashboarda u odnosu na vašu posljednju poznato-dobru kopiju.

Sljedeći koraci

Pokrenite FixVibe sken prema svom produkcijskom URL-u — provjera baas.clerk-auth0 flegira Clerk publishable ključeve, test ključeve u produkciji i bundled tajne ključeve. Za ekvivalentnu checklistu za Auth0, pogledajte Sigurnosnu checklistu za Auth0. Za pregled iz ptičje perspektive za BaaS providere, pročitajte Skener BaaS pogrešnih konfiguracija.