// docs / baas security / clerk hardening

Kontrolni seznam varnosti Clerk: 20 točk

Clerk za vašo aplikacijo opravlja avtentikacijo, seje in organizacije — kar pomeni, da je napačno konfigurirana integracija Clerk obhod avtentikacije, vektor fiksacije seje ali pot odtekanja organizacije. Ta kontrolni seznam je 20-točkovni pregled v ključih, konfiguraciji sej, webhookih, organizacijah, JWT-predlogah in tekočem spremljanju. UI-orodja za kodiranje Clerk hitro povežejo s smiselnimi privzetimi vrednostmi; ta seznam ujame točke, ki jih pustijo na mizi.

Za ozadje, zakaj so napačne konfiguracije na ravni avtentikacije šibka točka UI-orodij, glejte Zakaj UI-orodja za kodiranje puščajo varnostne vrzeli. Za vzporedni kontrolni seznam za Auth0 glejte Kontrolni seznam varnosti Auth0.

Okoljski ključi in seznam dovoljenih izvorov

Clerk izda dva različna ključa na projekt. Njihovo zamenjevanje ali odtekanje je prvi način odpovedi.

Uporabite objavljivi ključ (pk_live_* v produkciji, pk_test_* v razvoju) v brskalniku; skrivnostni ključ (sk_live_* / sk_test_*) uporabite samo na strežniku. Objavljivi ključ je v NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY varen; skrivnostni ključ ne sme nositi javne okoljske predpone in se nikoli ne sme pojaviti v odjemalski komponenti.
Preverite, da produkcijska aplikacija uporablja pk_live_*, ne pk_test_*. Testne instance dovolijo nepreverjene e-poštne naslove in onemogočeno MFA — izdajanje test-načina v produkcijo je obhod avtentikacije.
Konfigurirajte dovoljene izvore v nadzorni plošči Clerk. Settings → Domains → Allowed origins mora natančno navajati vašo produkcijsko domeno. Prazni ali nadomestni seznami izvorov omogočajo napadalcem ustvarjanje lažnih Clerk-vmesnikov, ki govorijo z vašim zaledjem.
Skrivnostni ključ zavrtite ob vsakem odhodu ali sumu odtekanja. Dashboard → API Keys → Reset. Stari ključ je razveljavljen; pred rotacijo izdajte strežniško kodo z novo vrednostjo.

Konfiguracija seje

Potek seje in časi nedejavnosti so razlika med ukradeno sejo kot 10-minutnim incidentom in 30-dnevnim.

Časomer nedejavnosti seje za SaaS-aplikacije, ki obdelujejo občutljive podatke, nastavite na 30 minut ali manj. Dashboard → Sessions → Inactivity timeout. Aplikacije bančnega tipa naj uporabljajo 5–10 minut; standardni SaaS 30–60 minut; potrošniške aplikacije 1–7 dni. Privzeta vrednost je 7 dni.
Omogočite preklic seje ob spremembi gesla, e-pošte in vpisu MFA. Dashboard → Sessions → Revoke on. To so uporabniško sproženi varnostni dogodki; obstoječe seje na drugih napravah je treba prekiniti.
Seje preverjajte na strani strežnika na vsaki zaščiteni poti, ne le ob prijavi. V Next.js: const { userId } = await auth(); v strežniški komponenti / API-poti prebere JWT iz piškotka in ga validira. Nikoli ne zaupajte preverjanju, ki temelji samo na piškotku.
Na piškotku seje nastavite SameSite=Lax (privzeto) ali Strict. Preverite v DevTools → Application → Cookies. SameSite=None je vektor CSRF — uporabite ga le, če ste izrecno konfigurirali avtentikacijo prek domen.

Preverjanje webhookov

Webhooki Clerk se sprožijo ob dogodkih življenjskega cikla uporabnika (created, updated, deleted, session.ended). So mehanizem sinhronizacije za vašo bazo podatkov — in ponarejen webhook je primitiv za pisanje v bazo podatkov.

Pri vsakem webhooku preverite podpis Svix. Clerk-webhooki so podpisani s Svix. Uporabite new Webhook(secret).verify(body, headers). Zavrnite z 401, če preverjanje ne uspe.
Skrivnost webhooka shranite v okoljski spremenljivki, nikoli v kodi. Skrivnost se zavrti ob vsaki regeneraciji v nadzorni plošči — vaša uvedba jo mora brati iz okolja, ne iz konstante.
Idempotentnost v vsakem rokovalniku. Dostavi webhookov se lahko ponavljajo. Uporabite glavo svix-id kot primarni ključ v tabeli webhook_events za odpravo dvojnikov. Spremembo stanja in vstavljanje idempotentnosti zavijte v isto transakcijo.
Ob user.deleted PII trdo izbrišite ali anonimizirajte v 24 urah. GDPR / CCPA to zahtevata. Preglejte pot brisanja: katere tabele hranijo podatke tega uporabnika? Kjer je mogoče, uporabite FK ON DELETE CASCADE.

Organizacije in dovoljenja

Če uporabljate Clerk Organizations, je meja organizacije vaša izolacija najemnikov. Vsaka strežniška poizvedba mora filtrirati po njej.

Na vsaki API-poti preberite tako userId kot orgId iz auth() in poizvedbe baze podatkov filtrirajte po obeh. WHERE org_id = $orgId AND user_id = $userId. Nikoli ne zaupajte org_id iz telesa zahteve.
<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.
Preizkusite izolacijo med organizacijami z dvema pravima organizacijskima računoma. Ustvarite organizacijo A, vnesite podatke, prijavite se v organizacijo B v drugem brskalniku, poskusite prek API-ja prebrati podatke organizacije A. Odziv mora biti 403 ali 404.

JWT-predloge in zunanje integracije

JWT-predloge potiskajo identiteto Clerk v Supabase, Firebase in druge spodaj ležeče storitve. Napačno konfigurirane predloge prek potrebnega delijo zahtevke ali razkrijejo podatke, ki jih niste mislili.

Za vsako JWT-predlogo navedite vsak zahtevek in potrdite, da je nujen. Dashboard → JWT Templates. Predloga, ki Supabase pošlje email in phone, izpostavi PII vsakomur, ki bere JWT v brskalniku.
Na JWT-predlogah, ki se uporabljajo za odjemalske klice navzdol, nastavite kratek čas veljavnosti. 60 sekund za zahteve API navzdol je standard. Dolgoživi JWT-ji so ukradeni in ponavljani.
Na strani prejema preverite zahtevek občinstva (aud). Supabase, Firebase itd. naj preverijo, da aud ustreza pričakovanemu identifikatorju storitve. Brez tega se lahko JWT, izdan za storitev A, avtenticira pri storitvi B.

Operativno spremljanje

Avtentikacija je najmočnejši vir signalov v dnevnikih, ki ga imate. Opazujte ga.

Alarmirajte ob skokih neuspelih prijav na IP / na račun. 50× normalna stopnja napak je napad s polnjenjem poverilnic. Clerk te dogodke pošilja na webhooke; usmerite jih v svoj SIEM.
Četrtletno pregledujte premik nastavitev seje in instance. Privzete vrednosti se s posodobitvami Clerk spreminjajo; „stare konfiguracije" sčasoma tiho postanejo napačne. Izvoz JSON iz nadzorne plošče primerjajte z zadnjo znano dobro kopijo.

Naslednji koraki

Zaženite FixVibe-pregled proti svojemu produkcijskemu URL-ju — pregled baas.clerk-auth0 označuje objavljive ključe Clerk, testne ključe v produkciji in pakirane skrivnostne ključe. Za enakovreden kontrolni seznam za Auth0 glejte Kontrolni seznam varnosti Auth0. Za krovni pregled BaaS-ponudnikov preberite Skener napačnih konfiguracij BaaS.