// 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 konfigurirana 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 toč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 pada.

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_*, a ne pk_test_*. Test instance dopuštaju neverificirane email adrese i onemogućen MFA — isporučivanje test moda u produkciju je auth bypass.
Konfigurirajte dopuštene origine u Clerk dashboardu. Settings → Domains → Allowed origins mora navoditi točno vašu produkcijsku domenu. Prazan popis origina ili popis s wildcardom dopuštaju napadačima da stvore lažne Clerk frontende koji razgovaraju s vašim backendom.
Rotirajte tajni ključ pri svakom odlasku ili sumnji u curenje. Dashboard → API Keys → Reset. Stari ključ se poništava; redeployajte 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 bankarske razine 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 konfigurirali postavku cross-domain autentifikacije.

Verifikacija webhookova

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

Verificirajte 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, a ne iz konstante.
Idempotentnost na svakom handleru. Isporuke webhookova mogu se ponoviti. Koristite header svix-id kao primarni ključ u tablici 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. Auditirajte putanju brisanja: koje tablice 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. Stvorite 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 vanjske integracije

JWT template guraju Clerk identitet u Supabase, Firebase i druge nizvodne servise. Pogrešno konfigurirani 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 tko č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.
Verificirajte 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 autentificirati 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 emitira ove događaje na webhookove; usmjerite 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. Diffajte 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 označava 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 pogled iz ptičje perspektive na BaaS providere, pročitajte Skener BaaS pogrešnih konfiguracija.