// docs / baas security / clerk hardening
Clerk security checklist: 20 আইটেম
Clerk আপনার অ্যাপের জন্য auth, sessions, এবং organizations পরিচালনা করে — অর্থাৎ একটি misconfigured Clerk integration একটি auth bypass, একটি session-fixation vector, বা একটি org-leakage path। এই checklist হল keys, session config, webhooks, organizations, JWT templates, এবং চলমান monitoring জুড়ে একটি 20-আইটেম audit। AI কোডিং টুলগুলি যুক্তিসঙ্গত defaults সহ Clerk দ্রুত wire করে; এই list সেই আইটেমগুলি ধরে যা তারা table-এ ছেড়ে দেয়।
auth-layer misconfigurations কেন একটি AI-tooling দুর্বল স্পট তার পটভূমির জন্য, AI কোডিং টুলগুলি কেন security gaps ছেড়ে দেয় দেখুন। Auth0-এর সমান্তরাল checklist-এর জন্য, Auth0 security checklist দেখুন।
Environment keys এবং origin allowlist
Clerk প্রতি project-এ দুটি স্বতন্ত্র keys issue করে। সেগুলি মিশ্রিত করা বা সেগুলি 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 অ্যাপ
pk_live_*ব্যবহার করে,pk_test_*নয়। Test instances unverified email addresses এবং disabled MFA-এর অনুমতি দেয় — production-এ test mode ship করা একটি auth bypass। - Clerk Dashboard-এ allowed origins configure করুন। Settings → Domains → Allowed origins-এ অবশ্যই আপনার production domain সঠিকভাবে তালিকাভুক্ত করতে হবে। খালি বা wildcard origin lists আক্রমণকারীদের rogue Clerk frontends তৈরি করতে দেয় যা আপনার backend-এর সাথে কথা বলে।
- যেকোনো departure বা সন্দেহজনক leak-এ secret key rotate করুন। Dashboard → API Keys → Reset। পুরানো key invalidated; rotating-এর আগে নতুন value সহ server-side code redeploy করুন।
Session configuration
Session expiry এবং idle timeouts হল একটি চুরি যাওয়া session 10-মিনিটের ঘটনা এবং একটি 30-দিনের মধ্যে পার্থক্য।
- সংবেদনশীল data পরিচালনা করে এমন SaaS অ্যাপগুলির জন্য session inactivity timeout 30 মিনিট বা কম set করুন। Dashboard → Sessions → Inactivity timeout। Banking-tier অ্যাপগুলি 5-10 মিনিট ব্যবহার করা উচিত; standard SaaS 30-60 মিনিট; consumer অ্যাপগুলি 1-7 দিন। Default হল 7 দিন।
- Password change, email change, এবং MFA enrollment-এ session revocation enable করুন। Dashboard → Sessions → Revoke on। এগুলি user-initiated security events; অন্যান্য devices-এ বিদ্যমান sessions kill করা উচিত।
- Sign-in-এ নয়, প্রতিটি protected route-এ server-side sessions যাচাই করুন। Next.js-এ: একটি server component / API route-এ
const { userId } = await auth();cookie থেকে JWT পড়ে এবং validate করে। একটি cookie-only check কখনো বিশ্বাস করবেন না। - Session cookie-তে
SameSite=Lax(default) বাStrictset করুন। DevTools → Application → Cookies-এ verify করুন।SameSite=Noneএকটি CSRF vector — যতক্ষণ আপনি স্পষ্টভাবে একটি cross-domain auth setup configure করেননি ততক্ষণ এটি ব্যবহার করবেন না।
Webhook verification
Clerk webhooks user lifecycle events-এ fire করে (created, updated, deleted, session.ended)। সেগুলি আপনার database-এর জন্য synchronization mechanism — এবং একটি forged webhook একটি database-write primitive।
- প্রতিটি webhook-এ Svix signature যাচাই করুন। Clerk webhooks Svix দ্বারা signed।
new Webhook(secret).verify(body, headers)ব্যবহার করুন। যাচাই fail হলে401দিয়ে reject করুন। - webhook secret একটি environment variable-এ সংরক্ষণ করুন, কোডে কখনোই নয়। 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.
- দুটি real 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 করে। Misconfigured templates claims over-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 set করুন। Downstream API requests-এর জন্য 60 সেকেন্ড স্ট্যান্ডার্ড। দীর্ঘস্থায়ী JWTs চুরি এবং replay হয়।
- Receiving side-এ audience (
aud) claim যাচাই করুন। Supabase, Firebase, ইত্যাদি check করা উচিত যেaudপ্রত্যাশিত service identifier-এর সাথে মেলে। এটি ছাড়া, service A-এর জন্য issued একটি JWT service B-তে authenticate করতে পারে।
Operational monitoring
Auth হল সর্বোচ্চ-সংকেত log source যা আপনার আছে। এটি দেখুন।
- Per IP / per account failed-login spikes-এ alert করুন। একটি 50× normal failure rate একটি credential-stuffing attack। Clerk এই events webhooks-এ emit করে; সেগুলিকে আপনার SIEM-এ route করুন।
- Session এবং instance settings drift-এর ত্রৈমাসিক পর্যালোচনা। Clerk update করার সাথে সাথে defaults পরিবর্তন হয়; "পুরানো configurations" সময়ের সাথে নীরবে ভুল হয়ে যায়। আপনার last-known-good 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 পড়ুন।