// docs / baas security / clerk hardening
បញ្ជីត្រួតពិនិត្យសុវត្ថិភាព Clerk៖ 20 ធាតុ
Clerk គ្រប់គ្រង auth, session និង organization សម្រាប់កម្មវិធីរបស់អ្នក — ដែលមានន័យថាការរួមបញ្ចូល Clerk ដែលកំណត់រចនាសម្ព័ន្ធខុសគឺជា auth bypass, វ៉ិចទ័រ session-fixation ឬផ្លូវ org-leakage។ បញ្ជីត្រួតពិនិត្យនេះគឺជាការត្រួតពិនិត្យ 20 ធាតុនៅទូទាំង key, ការកំណត់ session, webhook, organization, JWT template និងការតាមដានបន្ត។ ឧបករណ៍សរសេរកូដ AI ភ្ជាប់ Clerk ឱ្យលឿនជាមួយលំនាំដើមដែលសមរម្យ; បញ្ជីនេះចាប់ធាតុដែលពួកវាទុកនៅលើតុ។
សម្រាប់ផ្ទៃខាងក្រោយអំពីហេតុអ្វីការកំណត់រចនាសម្ព័ន្ធ auth-layer ខុសគឺជាចំណុចខ្សោយឧបករណ៍ AI, សូមមើល ហេតុអ្វីឧបករណ៍សរសេរកូដ AI ទុកគម្លាតសុវត្ថិភាព។ សម្រាប់បញ្ជីត្រួតពិនិត្យស្របគ្នាលើ Auth0, សូមមើល បញ្ជីត្រួតពិនិត្យសុវត្ថិភាព Auth0។
Environment key និង allowlist origin
Clerk ចេញ key ផ្សេងគ្នាពីរក្នុង project នីមួយៗ។ ការលាយពួកវា ឬការធ្វើឱ្យពួកវាលេចធ្លាយគឺជារបៀបបរាជ័យដំបូង។
- ប្រើ publishable key (
pk_live_*នៅក្នុងផលិតកម្ម,pk_test_*នៅក្នុង dev) នៅក្នុង browser; ប្រើ secret key (sk_live_*/sk_test_*) នៅ server តែប៉ុណ្ណោះ។ publishable key មានសុវត្ថិភាពនៅក្នុងNEXT_PUBLIC_CLERK_PUBLISHABLE_KEY; secret key មិនត្រូវផ្ទុក prefix env សាធារណៈ និងមិនត្រូវលេចឡើងនៅក្នុង component client ឡើយ។ - ផ្ទៀងផ្ទាត់ថាកម្មវិធីផលិតកម្មប្រើ
pk_live_*, មិនមែនpk_test_*។ Test instance អនុញ្ញាតអាស័យដ្ឋានអ៊ីមែលដែលមិនបានផ្ទៀងផ្ទាត់ និង MFA បិទ — ការ ship test mode ទៅផលិតកម្មគឺជា auth bypass។ - កំណត់រចនាសម្ព័ន្ធ origin ដែលអនុញ្ញាតនៅក្នុង Clerk Dashboard។ Settings → Domains → Allowed origins ត្រូវរាយ domain ផលិតកម្មរបស់អ្នកច្បាស់ៗ។ បញ្ជី origin ទទេ ឬ wildcard អនុញ្ញាតឱ្យអ្នកវាយប្រហារបង្កើត frontend Clerk ក្លែងក្លាយដែលនិយាយជាមួយ backend របស់អ្នក។
- បង្វិល secret key លើការចាកចេញណាមួយ ឬការសង្ស័យលេចធ្លាយ។ Dashboard → API Keys → Reset។ Key ចាស់ត្រូវបានបដិសេធ; redeploy កូដ server-side ជាមួយតម្លៃថ្មីមុនពេលបង្វិល។
ការកំណត់រចនាសម្ព័ន្ធ session
ការផុតកំណត់ session និង timeout អសកម្មគឺជាភាពខុសគ្នារវាង session ដែលលួចជាហេតុការណ៍ 10 នាទី និង 30 ថ្ងៃ។
- កំណត់ timeout អសកម្ម session ទៅ 30 នាទី ឬតិចជាងសម្រាប់កម្មវិធី SaaS ដែលគ្រប់គ្រងទិន្នន័យរសើប។ Dashboard → Sessions → Inactivity timeout។ កម្មវិធីកម្រិតធនាគារគួរប្រើ 5-10 នាទី; SaaS ស្តង់ដារ 30-60 នាទី; កម្មវិធីអ្នកប្រើ 1-7 ថ្ងៃ។ លំនាំដើមគឺ 7 ថ្ងៃ។
- បើកការដកហូត session លើការផ្លាស់ប្ដូរ password, ការផ្លាស់ប្ដូរអ៊ីមែល និងការចុះឈ្មោះ MFA។ Dashboard → Sessions → Revoke on។ ទាំងនេះគឺជាព្រឹត្តិការណ៍សុវត្ថិភាពដែលផ្ដួចផ្ដើមដោយអ្នកប្រើ; session ដែលមានស្រាប់នៅលើឧបករណ៍ផ្សេងគួរត្រូវសម្លាប់។
- ផ្ទៀងផ្ទាត់ session server-side លើរាល់ route ការពារ មិនមែនគ្រាន់តែនៅពេលចូល។ នៅក្នុង Next.js៖
const { userId } = await auth();នៅក្នុង server component / API route អាន JWT ពី cookie និងផ្ទៀងផ្ទាត់វា។ មិនត្រូវជឿការត្រួតពិនិត្យ cookie តែប៉ុណ្ណោះឡើយ។ - កំណត់
SameSite=Lax(លំនាំដើម) ឬStrictលើ cookie session។ ផ្ទៀងផ្ទាត់នៅក្នុង DevTools → Application → Cookies។SameSite=Noneគឺជាវ៉ិចទ័រ CSRF — មិនដែលប្រើវាលុះត្រាតែអ្នកបានកំណត់រចនាសម្ព័ន្ធ auth cross-domain ច្បាស់លាស់។
ការផ្ទៀងផ្ទាត់ webhook
Webhook Clerk ដំណើរការលើព្រឹត្តិការណ៍វដ្ដជីវិតរបស់អ្នកប្រើ (created, updated, deleted, session.ended)។ ពួកវាគឺជាយន្តការ synchronization សម្រាប់ database របស់អ្នក — និង webhook ក្លែងក្លាយគឺជា primitive សរសេរ database។
- ផ្ទៀងផ្ទាត់ហត្ថលេខា Svix លើ webhook នីមួយៗ។ Webhook Clerk ត្រូវបានចុះហត្ថលេខាដោយ Svix។ ប្រើ
new Webhook(secret).verify(body, headers)។ បដិសេធជាមួយ401បើការផ្ទៀងផ្ទាត់បរាជ័យ។ - រក្សា webhook secret នៅក្នុង environment variable, មិនមែននៅក្នុងកូដឡើយ។ Secret បង្វិលលើការបង្កើតថ្មី Dashboard នីមួយៗ — deploy របស់អ្នកត្រូវអានវាពី env មិនមែនពី constant ឡើយ។
- Idempotency លើ handler រាល់។ ការដឹកជញ្ជូន Webhook អាចធ្វើម្ដងទៀត។ ប្រើ header
svix-idជា primary key នៅក្នុងតារាងwebhook_eventsដើម្បីលុបស្ទួន។ រុំការផ្លាស់ប្ដូរស្ថានភាព និងការ insert idempotency នៅក្នុង transaction ដូចគ្នា។ - នៅពេល
user.deleted, លុបយ៉ាងរឹង ឬ anonymize PII ក្នុង 24 ម៉ោង។ GDPR / CCPA ត្រូវការវា។ ត្រួតពិនិត្យផ្លូវលុប៖ តារាងណាមួយដែលកាន់ទិន្នន័យអ្នកប្រើនេះ? ប្រើ FK ON DELETE CASCADE កន្លែងដែលអ្នកអាច។
Organization និងសិទ្ធិ
បើអ្នកប្រើ Clerk Organization, ព្រំដែន org គឺជាការដាច់ស្រយាល tenant របស់អ្នក។ រាល់ query database server-side ត្រូវត្រងតាមវា។
- នៅរាល់ API route, អានទាំង
userIdនិងorgIdពីauth()និងត្រង query database តាមទាំងពីរ។WHERE org_id = $orgId AND user_id = $userId។ មិនត្រូវជឿorg_idពី body request ឡើយ។ - <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.
- សាកល្បងការដាច់ស្រយាល cross-org ជាមួយគណនី org ពិតពីរ។ បង្កើត Org A, បំពេញទិន្នន័យ, ចូល Org B នៅក្នុង browser ផ្សេង, ព្យាយាមអានទិន្នន័យ Org A តាមរយៈ API។ Response ត្រូវជា
403ឬ404។
JWT template និងការរួមបញ្ចូលខាងក្រៅ
JWT template រុញអត្តសញ្ញាណ Clerk ទៅ Supabase, Firebase និងសេវាកម្ម downstream ផ្សេងទៀត។ Template ដែលកំណត់រចនាសម្ព័ន្ធខុសចែករំលែក claim ខ្លាំងពេក ឬបង្ហាញទិន្នន័យដែលអ្នកមិនមានបំណង។
- សម្រាប់ JWT template នីមួយៗ, រាយរាល់ claim និងបញ្ជាក់ថាវាចាំបាច់។ Dashboard → JWT Templates។ Template ដែល ship
emailនិងphoneទៅ Supabase បង្ហាញ PII ដល់នរណាក៏ដោយដែលអាន JWT នៅក្នុង browser។ - កំណត់ការផុតកំណត់ខ្លីលើ JWT template ដែលប្រើសម្រាប់ការហៅ downstream client-side។ 60 វិនាទីសម្រាប់ request API downstream គឺជាស្ដង់ដារ។ JWT ដែលរស់នៅយូរត្រូវបានលួច និងផ្ដល់ឡើងវិញ។
- ផ្ទៀងផ្ទាត់ claim audience (
aud) នៅខាងទទួល។ Supabase, Firebase ល។ គួរត្រួតពិនិត្យថាaudត្រូវនឹង service identifier ដែលរំពឹង។ ដោយគ្មាននេះ, JWT ដែលចេញសម្រាប់ service A អាច authenticate ទៅ service B។
ការតាមដានប្រតិបត្តិការ
Auth គឺជាប្រភព log សញ្ញាខ្ពស់បំផុតដែលអ្នកមាន។ មើលវា។
- ដាស់តឿនលើ spike ការចូលបរាជ័យក្នុង IP / ក្នុងគណនី។ អត្រាបរាជ័យធម្មតា 50× គឺជាការវាយប្រហារ credential-stuffing។ Clerk បញ្ចេញព្រឹត្តិការណ៍ទាំងនេះទៅ webhook; បញ្ជូនពួកវាទៅ SIEM របស់អ្នក។
- ការពិនិត្យប្រចាំត្រីមាសនៃការរសាត់ការកំណត់ session និង instance។ លំនាំដើមផ្លាស់ប្ដូរនៅពេល Clerk update; "ការកំណត់ចាស់" ស្ងាត់ៗក្លាយជាខុសតាមពេលវេលា។ Diff Dashboard JSON export ប្រឆាំងនឹងច្បាប់ចម្លងដែលគេស្គាល់-ល្អចុងក្រោយរបស់អ្នក។
ជំហានបន្ទាប់
ដំណើរការ FixVibe scan ប្រឆាំងនឹង URL ផលិតកម្មរបស់អ្នក — ការត្រួតពិនិត្យ baas.clerk-auth0 សម្គាល់ publishable key Clerk, test key នៅក្នុងផលិតកម្ម និង secret key ដែល bundled។ សម្រាប់បញ្ជីត្រួតពិនិត្យស្មើគ្នាលើ Auth0, សូមមើល បញ្ជីត្រួតពិនិត្យសុវត្ថិភាព Auth0។ សម្រាប់ទិដ្ឋភាពទូទៅនៅទូទាំង BaaS provider, សូមអាន BaaS misconfiguration scanner។