// docs / baas security / clerk hardening
Clerk security checklist: 20 आइटम
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-आइटम audit है। AI कोडिंग टूल समझदार defaults के साथ Clerk को जल्दी से wire करते हैं; यह सूची उन आइटमों को पकड़ती है जिन्हें वे table पर छोड़ देते हैं।
Auth-layer misconfigurations AI-tooling कमजोर स्थान क्यों हैं, इसकी पृष्ठभूमि के लिए, 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 keyNEXT_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 को सटीक रूप से सूचीबद्ध करना चाहिए। खाली या wildcard origin lists हमलावरों को rogue Clerk frontends बनाने देती हैं जो आपके backend से बात करते हैं।
- किसी भी प्रस्थान या संदिग्ध leak पर secret key rotate करें। Dashboard → API Keys → Reset। पुरानी key अमान्य है; rotation से पहले नए मान के साथ server-side कोड redeploy करें।
Session कॉन्फ़िगरेशन
Session expiry और idle timeouts चुराई गई session के 10-मिनट की incident होने या 30-दिन की होने के बीच का अंतर हैं।
- संवेदनशील data handle करने वाली SaaS apps के लिए session inactivity timeout 30 मिनट या उससे कम पर सेट करें। Dashboard → Sessions → Inactivity timeout। Banking-tier apps को 5-10 मिनट का उपयोग करना चाहिए; मानक SaaS 30-60 मिनट; consumer apps 1-7 दिन। Default 7 दिन है।
- Password change, email change, और MFA enrollment पर session revocation enable करें। Dashboard → Sessions → Revoke on। ये user-initiated security events हैं; अन्य devices पर existing sessions को killed किया जाना चाहिए।
- केवल sign-in पर नहीं, हर protected route पर server-side sessions verify करें। Next.js में: एक server component / API route में
const { userId } = await auth();cookie से JWT पढ़ता है और इसे validate करता है। केवल-cookie check पर कभी भरोसा न करें। - Session cookie पर
SameSite=Lax(default) याStrictसेट करें। DevTools → Application → Cookies में verify करें।SameSite=Noneएक CSRF vector है — कभी इसका उपयोग न करें जब तक आपने स्पष्ट रूप से एक 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 करें, कभी कोड में नहीं। Secret हर Dashboard regeneration पर rotate होता है — आपके deploy को इसे env से पढ़ना चाहिए, constant से नहीं।
- हर handler पर Idempotency। Webhook deliveries दोहरा सकती हैं। Dedupe के लिए
webhook_eventstable में primary key के रूप मेंsvix-idheader का उपयोग करें। State change और idempotency insert को एक ही transaction में wrap करें। user.deletedपर, 24 घंटों के भीतर PII को hard-delete या anonymize करें। GDPR / CCPA इसकी आवश्यकता है। Deletion path का audit करें: कौन-सी tables इस user के data को रखती हैं? जहाँ आप कर सकते हैं वहाँ 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 का परीक्षण करें। 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 को अधिक share करते हैं या ऐसा data expose करते हैं जो आपका इरादा नहीं था।
- हर JWT template के लिए, हर claim सूचीबद्ध करें और confirm करें कि यह आवश्यक है। Dashboard → JWT Templates। एक template जो Supabase को
emailऔरphoneship करता है, browser में JWT पढ़ने वाले किसी को भी PII expose करता है। - Client-side downstream calls के लिए उपयोग किए जाने वाले JWT templates पर short expiry सेट करें। Downstream API requests के लिए 60 seconds मानक है। Long-lived JWTs चुराए और replay किए जाते हैं।
- Receiving side पर audience (
aud) claim verify करें। Supabase, Firebase, आदि को check करना चाहिए किaudअपेक्षित 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 हमला है। Clerk इन events को webhooks पर emit करता है; उन्हें अपने SIEM पर route करें।
- Session और instance settings drift की त्रैमासिक समीक्षा। Defaults बदलते हैं जब Clerk update करता है; "पुराने कॉन्फ़िगरेशन" समय के साथ चुपचाप गलत हो जाते हैं। अपनी पिछली-ज्ञात-अच्छी 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 पढ़ें।