// docs / baas security / clerk hardening

Checklist sa seguridad ng Clerk: 20 items

Ang Clerk ay humahawak ng auth, sessions, at organizations para sa iyong app — na nangangahulugang ang maling konpigurado na Clerk integration ay isang auth bypass, isang session-fixation vector, o isang org-leakage path. Ang checklist na ito ay isang 20-item na audit sa mga keys, session config, webhooks, organizations, JWT templates, at patuloy na monitoring. Mabilis na ikinakabit ng AI coding tools ang Clerk gamit ang mga makatuwirang defaults; ang listahan na ito ay nakakahuli sa mga items na iniiwan nila sa mesa.

Para sa background kung bakit ang mga maling konpigurasyon sa auth-layer ay isang mahinang punto ng AI tooling, tingnan ang Bakit nag-iiwan ng mga puwang sa seguridad ang mga AI coding tools. Para sa parallel checklist sa Auth0, tingnan ang Checklist sa seguridad ng Auth0.

Mga environment key at origin allowlist

Naglalabas ang Clerk ng dalawang magkaibang keys bawat project. Ang paghahalo o pag-leak sa kanila ang unang failure mode.

Gamitin ang publishable key (pk_live_* sa produksyon, pk_test_* sa dev) sa browser; gamitin ang secret key (sk_live_* / sk_test_*) sa server lamang. Ligtas ang publishable key sa NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; ang secret key ay hindi dapat magdala ng public env prefix at hindi dapat lumitaw sa isang client component.
I-verify na ang production app ay gumagamit ng pk_live_*, hindi pk_test_*. Ang mga test instance ay nagpapahintulot sa mga unverified email address at naka-disable na MFA — ang pag-deploy ng test mode sa produksyon ay isang auth bypass.
I-configure ang mga pinapayagang origins sa Clerk Dashboard. Settings → Domains → Allowed origins ay dapat magtala ng iyong production domain nang eksakto. Ang walang laman o wildcard origin lists ay nagpapahintulot sa mga umaatake na gumawa ng mga rogue Clerk frontend na nakikipag-usap sa iyong backend.
I-rotate ang secret key sa anumang pag-alis o pinaghihinalaang leak. Dashboard → API Keys → Reset. Ang lumang key ay na-invalidate; i-deploy muli ang server-side code na may bagong value bago mag-rotate.

Konpigurasyon ng session

Ang session expiry at idle timeouts ang pagkakaiba sa pagitan ng isang nakaw na session na isang 10-minutong insidente at isang 30-araw.

Itakda ang session inactivity timeout sa 30 minuto o mas kaunti para sa mga SaaS app na humahawak ng sensitibong data. Dashboard → Sessions → Inactivity timeout. Ang mga banking-tier app ay dapat gumamit ng 5-10 minuto; standard SaaS 30-60 minuto; consumer apps 1-7 araw. Ang default ay 7 araw.
I-enable ang session revocation sa pagpapalit ng password, pagpapalit ng email, at pagpa-enroll ng MFA. Dashboard → Sessions → Revoke on. Ang mga ito ay mga user-initiated security events; ang mga umiiral na session sa iba pang device ay dapat patayin.
I-verify ang mga session server-side sa bawat protektadong route, hindi lamang sa sign-in. Sa Next.js: const { userId } = await auth(); sa isang server component / API route ay nagbabasa ng JWT mula sa cookie at nagpapatibay nito. Huwag kailanman magtiwala sa isang cookie-only check.
Itakda ang SameSite=Lax (default) o Strict sa session cookie. I-verify sa DevTools → Application → Cookies. Ang SameSite=None ay isang CSRF vector — huwag kailanman gamitin maliban kung tahasan kang nag-configure ng cross-domain auth setup.

Webhook verification

Ang Clerk webhooks ay nag-fire sa mga user lifecycle event (created, updated, deleted, session.ended). Ang mga ito ang synchronization mechanism para sa iyong database — at ang isang pekeng webhook ay isang database-write primitive.

I-verify ang Svix signature sa bawat webhook. Ang Clerk webhooks ay pinirmahan ng Svix. Gumamit ng new Webhook(secret).verify(body, headers). Tanggihan ng 401 kung nabigo ang verification.
Itago ang webhook secret sa isang environment variable, hindi sa code. Ang secret ay nag-ro-rotate sa bawat Dashboard regeneration — ang iyong deploy ay dapat magbasa nito mula sa env, hindi mula sa isang constant.
Idempotency sa bawat handler. Maaaring mag-ulit ang mga webhook deliveries. Gamitin ang svix-id header bilang primary key sa isang webhook_events table upang i-dedupe. Ibalot ang state change at ang idempotency insert sa parehong transaction.
Sa user.deleted, hard-delete o anonymize ang PII sa loob ng 24 oras. Hinihingi ito ng GDPR / CCPA. I-audit ang deletion path: aling mga talahanayan ang humahawak ng data ng user na ito? Gamitin ang FK ON DELETE CASCADE kung kaya mo.

Mga organisasyon at permission

Kung gagamitin mo ang Clerk Organizations, ang org boundary ay ang iyong tenant isolation. Ang bawat server-side query ay dapat mag-filter sa pamamagitan nito.

Sa bawat API route, basahin ang parehong userId at orgId mula sa auth() at i-filter ang mga database queries sa pamamagitan ng pareho. WHERE org_id = $orgId AND user_id = $userId. Huwag kailanman magtiwala sa org_id mula sa request body.
<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.
I-test ang cross-org isolation gamit ang dalawang tunay na org account. Gumawa ng Org A, ipuno ng data, mag-sign in sa Org B sa ibang browser, subukang basahin ang data ng Org A sa pamamagitan ng API. Ang response ay dapat na 403 o 404.

Mga JWT template at external integrations

Itinutulak ng JWT templates ang Clerk identity sa Supabase, Firebase, at iba pang downstream services. Ang maling konpigurado na mga template ay nagsasalig nang labis ng claims o nagpapakita ng data na hindi mo sinadya.

Para sa bawat JWT template, ilista ang bawat claim at kumpirmahin na kinakailangan ito. Dashboard → JWT Templates. Ang isang template na nagpapadala ng email at phone sa Supabase ay nagpapakita ng PII sa sinumang nagbabasa ng JWT sa browser.
Magtakda ng maikling expiry sa mga JWT template na ginagamit para sa client-side downstream calls. 60 segundo para sa downstream API requests ay ang pamantayan. Ang mas mahaba-buhay na JWTs ay ninanakaw at inu-replay.
I-verify ang audience (aud) claim sa receiving side. Ang Supabase, Firebase, atbp. ay dapat mag-check na ang aud ay tumutugma sa inaasahang service identifier. Kung wala ito, ang JWT na nai-issue para sa service A ay maaaring mag-authenticate sa service B.

Operational monitoring

Ang auth ay ang pinakamataas-na-signal na log source na mayroon ka. Bantayan ito.

Mag-alerto sa failed-login spikes bawat IP / bawat account. Ang 50× normal failure rate ay isang credential-stuffing attack. Inilalabas ng Clerk ang mga event na ito sa mga webhooks; ipadala sila sa iyong SIEM.
Quarterly review ng session at instance settings drift. Nagbabago ang mga default habang nag-uupdate ang Clerk; ang "lumang configurations" ay tahimik na nagiging mali sa paglipas ng panahon. I-diff ang Dashboard JSON export laban sa iyong huling-kilalang-magandang kopya.

Mga susunod na hakbang

Magpatakbo ng FixVibe scan laban sa iyong production URL — ang baas.clerk-auth0 check ay nagba-flag ng mga Clerk publishable keys, test keys sa produksyon, at mga bundled secret keys. Para sa katumbas na checklist sa Auth0, tingnan ang Checklist sa seguridad ng Auth0. Para sa pangkalahatang tanaw sa mga BaaS provider, basahin ang BaaS misconfiguration scanner.