// docs / baas security / clerk hardening

Clerk biztonsági checklist: 20 pont

A Clerk kezeli az auth-ot, a sessionöket és a szervezeteket az alkalmazásodhoz — ami azt jelenti, hogy egy hibásan konfigurált Clerk-integráció egy auth-megkerülés, egy session-fixáció vektor vagy egy org-szivárgási útvonal. Ez a checklist egy 20-pontos audit kulcsokon, session-konfigon, webhookokon, szervezeteken, JWT-sablonokon és folyamatos monitorozáson keresztül. Az MI-kódoló eszközök gyorsan bedrótozzák a Clerket értelmes alapértelmezésekkel; ez a lista elkapja azokat a pontokat, amiket az asztalon hagynak.

Háttérinformációért arról, hogy az auth-rétegbeli hibás konfigurációk miért egy MI-tooling gyenge pont, lásd Miért hagynak biztonsági réseket az MI-kódoló eszközök. Az Auth0 párhuzamos checklistjéért lásd Auth0 biztonsági checklist.

Környezeti kulcsok és origin-allowlist

A Clerk két különböző kulcsot ad ki projektenként. Ezek keverése vagy kiszivárogtatása az első hibamód.

Használd a publishable kulcsot (pk_live_* produkcióban, pk_test_* dev-ben) a böngészőben; használd a secret kulcsot (sk_live_* / sk_test_*) csak a szerveren. A publishable kulcs biztonságos a NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY-ben; a secret kulcs soha nem hordozhat nyilvános env előtagot, és soha nem szabad megjelennie egy kliens komponensben.
Ellenőrizd, hogy a produkciós alkalmazás pk_live_*-ot használ, nem pk_test_*-ot. A teszt-példányok megengedik a nem ellenőrzött e-mail-címeket és a letiltott MFA-t — teszt módot élesíteni auth-megkerülés.
Konfiguráld az engedélyezett origin-eket a Clerk Dashboardon. Settings → Domains → Allowed origins-nek pontosan listáznia kell a produkciós doménedet. Az üres vagy wildcard origin-listák lehetővé teszik a támadóknak, hogy rosszindulatú Clerk-frontendeket hozzanak létre, amelyek a backendeddel beszélnek.
Rotáld a secret kulcsot bármilyen távozás vagy gyanús szivárgás esetén. Dashboard → API Keys → Reset. A régi kulcs érvénytelenné válik; deployold újra a szerveroldali kódot az új értékkel a rotáció előtt.

Session-konfiguráció

A session-lejárat és a tétlenségi időtúllépés a különbség aközött, hogy egy ellopott session 10 perces incidens vagy 30 napos.

Állítsd a session-tétlenségi időtúllépést 30 percre vagy kevesebbre érzékeny adatokat kezelő SaaS-alkalmazásokhoz. Dashboard → Sessions → Inactivity timeout. Banki szintű alkalmazásoknak 5-10 percet kell használniuk; standard SaaS-nek 30-60 percet; fogyasztói alkalmazásoknak 1-7 napot. Az alapértelmezett 7 nap.
Engedélyezd a session-visszavonást jelszóváltáskor, e-mail-változtatáskor és MFA-regisztrációkor. Dashboard → Sessions → Revoke on. Ezek felhasználó-kezdeményezett biztonsági események; a más eszközökön lévő meglévő sessionöket meg kell ölni.
Ellenőrizd a sessionöket szerveroldalon minden védett útvonalon, ne csak bejelentkezéskor. A Next.js-ben: const { userId } = await auth(); egy szerverkomponensben / API-route-ban kiolvassa a JWT-t a cookie-ból és érvényesíti. Soha ne bízz csak-cookie-ellenőrzésben.
Állítsd a SameSite=Lax-ot (alapértelmezett) vagy Strict-et a session-cookie-n. Ellenőrizd a DevTools → Application → Cookies-ban. A SameSite=None CSRF-vektor — soha ne használd, hacsak nem explicit módon konfiguráltál egy cross-domain auth-felépítést.

Webhook-ellenőrzés

A Clerk webhookok felhasználó-életciklus eseményekre tüzelnek (created, updated, deleted, session.ended). Ezek a szinkronizációs mechanizmus az adatbázisodhoz — és egy hamisított webhook egy adatbázis-írási primitív.

Ellenőrizd a Svix-aláírást minden webhookon. A Clerk webhookjait a Svix írja alá. Használd a new Webhook(secret).verify(body, headers)-t. Utasítsd el 401-gyel, ha az ellenőrzés sikertelen.
Tárold a webhook-titkot környezeti változóban, soha kódban. A titok minden Dashboard-regenerálással rotálódik — a deployodnak env-ből kell olvasnia, nem konstansból.
Idempotencia minden handleren. A webhook-szállítások ismétlődhetnek. Használd az svix-id fejlécet elsődleges kulcsként egy webhook_events táblában a duplikátumok kiszűréséhez. Csomagold az állapotváltozást és az idempotencia-beszúrást ugyanabba a tranzakcióba.
A user.deleted-en hard-delete-eld vagy anonimizáld a PII-t 24 órán belül. A GDPR / CCPA megköveteli. Auditáld a törlési útvonalat: melyik táblák tartalmaznak ennek a felhasználónak az adatait? Használd az FK ON DELETE CASCADE-et, ahol tudod.

Szervezetek és jogosultságok

Ha Clerk Organizations-t használsz, az org-határ a tenant-izolációd. Minden szerveroldali lekérdezésnek szűrnie kell rá.

Minden API-route-on olvasd ki mind a userId-t, mind az orgId-t az auth()-ból, és szűrd az adatbázis-lekérdezéseket mindkettőre. WHERE org_id = $orgId AND user_id = $userId. Soha ne bízz a kérés törzséből származó org_id-ban.
<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.
Teszteld a cross-org izolációt két valódi org-fiókkal. Hozd létre A Org-ot, töltsd fel adatokkal, jelentkezz be B Org-ba egy másik böngészőben, próbáld olvasni A Org adatait az API-n keresztül. A válasznak 403-nak vagy 404-nek kell lennie.

JWT-sablonok és külső integrációk

A JWT-sablonok a Clerk identitást a Supabase-be, Firebase-be és más downstream szolgáltatásokba tolják. A hibásan konfigurált sablonok túl sok claimet osztanak meg, vagy olyan adatokat exponálnak, amelyeket nem szándékoztál.

Minden JWT-sablonnál listázz ki minden claimet, és erősítsd meg, hogy szükséges. Dashboard → JWT Templates. Egy sablon, ami email-t és phone-t küld a Supabase-be, PII-t exponál bárkinek, aki a JWT-t a böngészőben olvassa.
Állíts rövid lejáratot a kliensoldali downstream hívásokhoz használt JWT-sablonoknál. 60 másodperc a standard a downstream API-kérésekhez. A hosszabb élettartamú JWT-ket ellopják és visszajátsszák.
Ellenőrizd az audience (aud) claimet a fogadó oldalon. A Supabase-nek, Firebase-nek stb. ellenőriznie kell, hogy az aud megegyezik az elvárt szolgáltatás-azonosítóval. Enélkül egy A szolgáltatáshoz kiadott JWT képes hitelesíteni a B szolgáltatáshoz.

Üzemeltetési monitorozás

Az auth a legmagasabb jelszintű log-forrásod. Figyelj rá.

Riasszon a sikertelen bejelentkezési csúcsokra IP-nként / fiókonként. Egy 50× normál hibaarány credential stuffing támadás. A Clerk ezeket az eseményeket webhookokra emitálja; routeold a SIEM-edbe.
Negyedéves felülvizsgálat a session- és példány-beállítások sodródásáról. Az alapértelmezések változnak, ahogy a Clerk frissül; a „régi konfigurációk" csendben rosszá válnak idővel. Diffeld a Dashboard JSON-exportot az utolsó ismert-jó példányoddal.

Következő lépések

Futtass egy FixVibe-szkennelést az éles URL-edre — a baas.clerk-auth0 ellenőrzés jelzi a Clerk publishable kulcsokat, a teszt kulcsokat produkcióban és a bundle-be ágyazott secret kulcsokat. Az Auth0 párhuzamos checklistjéért lásd Auth0 biztonsági checklist. A BaaS-szolgáltatókra kiterjedő átfogó áttekintésért olvasd el a BaaS hibás konfiguráció szkenner cikket.