// docs / baas security / clerk hardening

Clerk security checklist: 20 items

Clerk તમારી app માટે auth, sessions, અને organizations handle કરે છે — જેનો અર્થ છે ખોટી રીતે કોન્ફિગર કરેલ Clerk integration auth bypass, session-fixation vector, અથવા org-leakage path છે. આ checklist keys, session config, webhooks, organizations, JWT templates, અને ongoing monitoring માં 20-item audit છે. AI કોડિંગ ટૂલ Clerk ને સમજદાર defaults સાથે ઝડપથી wire up કરે છે; આ list એ items પકડે છે જે તેઓ table પર છોડે છે.

Auth-layer misconfigurations AI-tooling weak spot કેમ છે તેની background માટે, AI કોડિંગ ટૂલ security gaps કેમ છોડે છે જુઓ. Auth0 પર સમાંતર checklist માટે, Auth0 security checklist જુઓ.

Environment keys અને origin allowlist

Clerk પ્રતિ project બે અલગ keys ઈશ્યુ કરે છે. તેમને મિક્સ કરવી અથવા leak કરવી એ પ્રથમ failure mode છે.

Browser માં publishable key (production માં pk_live_*, dev માં pk_test_*) નો ઉપયોગ કરો; ફક્ત server પર secret key (sk_live_* / sk_test_*) નો ઉપયોગ કરો. Publishable key NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY માં સુરક્ષિત છે; secret key ને ક્યારેય public env prefix ન કરવો જોઈએ અને client component માં ક્યારેય દેખાવો ન જોઈએ.
Verify કરો કે production app pk_test_* નહીં, pk_live_* નો ઉપયોગ કરે છે. Test instances unverified email addresses અને disabled MFA ની મંજૂરી આપે છે — production માં test mode ship કરવો એ auth bypass છે.
Clerk Dashboard માં allowed origins કોન્ફિગર કરો. Settings → Domains → Allowed origins તમારા production domain ને ચોક્કસ list કરવો જોઈએ. Empty અથવા wildcard origin lists હુમલાખોરો ને rogue Clerk frontends બનાવવા દે છે જે તમારા backend સાથે વાત કરે છે.
કોઈપણ વિદાય અથવા શંકાસ્પદ leak પર secret key rotate કરો. Dashboard → API Keys → Reset. જૂની key invalidate થાય છે; rotation પહેલા નવા value સાથે server-side code redeploy કરો.

Session configuration

Session expiry અને idle timeouts એ ચોરી થયેલ session 10-minute incident હોવા અને 30-day હોવા વચ્ચે નો તફાવત છે.

સંવેદનશીલ data handle કરતી SaaS apps માટે session inactivity timeout 30 minutes અથવા તેનાથી ઓછું સેટ કરો. Dashboard → Sessions → Inactivity timeout. Banking-tier apps એ 5-10 minutes નો ઉપયોગ કરવો જોઈએ; standard SaaS 30-60 minutes; consumer apps 1-7 days. Default 7 days છે.
Password change, email change, અને MFA enrollment પર session revocation enable કરો. Dashboard → Sessions → Revoke on. આ user-initiated security events છે; અન્ય devices પર existing sessions kill થવા જોઈએ.
ફક્ત sign-in પર નહીં, દરેક protected route પર server-side sessions verify કરો. Next.js માં: server component / API route માં const { userId } = await auth(); cookie માંથી JWT વાંચે છે અને તેને validate કરે છે. Cookie-only check પર ક્યારેય ભરોસો ન કરો.
Session cookie પર SameSite=Lax (default) અથવા Strict સેટ કરો. DevTools → Application → Cookies માં verify કરો. SameSite=None CSRF vector છે — જ્યાં સુધી તમે explicit રીતે cross-domain auth setup કોન્ફિગર નથી કર્યું ત્યાં સુધી ક્યારેય તેનો ઉપયોગ ન કરો.

Webhook verification

Clerk webhooks user lifecycle events (created, updated, deleted, session.ended) પર fire થાય છે. તેઓ તમારા database માટે synchronization mechanism છે — અને forged webhook database-write primitive છે.

દરેક webhook પર Svix signature verify કરો. Clerk webhooks Svix દ્વારા signed છે. new Webhook(secret).verify(body, headers) નો ઉપયોગ કરો. જો verification fail થાય તો 401 સાથે reject કરો.
Webhook secret ને environment variable માં store કરો, ક્યારેય code માં નહીં. Secret દરેક Dashboard regeneration પર rotate થાય છે — તમારા deploy એ તેને env માંથી વાંચવું જોઈએ, constant માંથી નહીં.
દરેક handler પર Idempotency. Webhook deliveries પુનરાવર્તિત થઈ શકે છે. Dedupe માટે webhook_events table માં primary key તરીકે svix-id header નો ઉપયોગ કરો. State change અને idempotency insert ને એ જ transaction માં wrap કરો.
user.deleted પર, 24 hours ની અંદર PII ને hard-delete અથવા anonymize કરો. GDPR / CCPA તેની જરૂર છે. Deletion path નું audit કરો: કઈ tables આ user નો data hold કરે છે? જ્યાં તમે કરી શકો ત્યાં FK ON DELETE CASCADE નો ઉપયોગ કરો.

Organizations અને permissions

જો તમે Clerk Organizations નો ઉપયોગ કરો છો, તો org boundary તમારી tenant isolation છે. દરેક server-side query તેના દ્વારા filter થવી જોઈએ.

દરેક API route પર, auth() માંથી userId અને orgId બંને વાંચો અને database queries ને બંને દ્વારા filter કરો. WHERE org_id = $orgId AND user_id = $userId. Request body માંથી org_id પર ક્યારેય ભરોસો ન કરો.
<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.
બે વાસ્તવિક org accounts સાથે cross-org isolation test કરો. Org A બનાવો, data populate કરો, બીજા browser માં Org B માં sign in કરો, API મારફતે Org A નો data વાંચવાનો પ્રયાસ કરો. Response 403 અથવા 404 હોવો જોઈએ.

JWT templates અને external integrations

JWT templates Clerk identity ને Supabase, Firebase, અને અન્ય downstream services માં push કરે છે. ખોટી રીતે કોન્ફિગર કરેલ templates claims ને over-share કરે છે અથવા એવો data expose કરે છે જે તમારો અર્થ નહોતો.

દરેક JWT template માટે, દરેક claim list કરો અને confirm કરો કે તે જરૂરી છે. Dashboard → JWT Templates. Supabase ને email અને phone ship કરતું template browser માં JWT વાંચતા કોઈને પણ PII expose કરે છે.
Client-side downstream calls માટે ઉપયોગમાં લેવાતા JWT templates પર short expiry સેટ કરો. Downstream API requests માટે 60 seconds standard છે. Longer-lived JWTs ચોરી અને replay થાય છે.
Receiving side પર audience (aud) claim verify કરો. Supabase, Firebase, વગેરે એ check કરવું જોઈએ કે aud expected service identifier સાથે મેળ ખાય છે. તેના વગર, service A માટે ઈશ્યુ થયેલ JWT service B પર authenticate કરી શકે છે.

Operational monitoring

Auth તમારી પાસેનો સૌથી ઉચ્ચ-signal log source છે. તેને જુઓ.

Per IP / per account failed-login spikes પર alert કરો. સામાન્ય failure rate કરતા 50× credential-stuffing attack છે. Clerk આ events ને webhooks પર emit કરે છે; તેમને તમારા SIEM પર route કરો.
Session અને instance settings drift ની ત્રિમાસિક સમીક્ષા. જેમ જેમ Clerk update કરે છે ડિફોલ્ટ બદલાય છે; "જૂના configurations" સમય સાથે ચૂપચાપ ખોટા થાય છે. તમારી છેલ્લી-જાણીતી-સારી copy સામે Dashboard JSON export ને diff કરો.

આગળના પગલાં

તમારા production URL સામે FixVibe scan ચલાવો — baas.clerk-auth0 check Clerk publishable keys, production માં test keys, અને bundled secret keys ને flag કરે છે. Auth0 પર સમકક્ષ checklist માટે, Auth0 security checklist જુઓ. BaaS providers માં umbrella દૃશ્ય માટે, BaaS misconfiguration scanner વાંચો.