FixVibe

// docs / baas security / auth0 hardening

បញ្ជីត្រួតពិនិត្យសុវត្ថិភាព Auth0៖ 22 ធាតុ

Auth0 គឺជាវេទិកា identity-as-a-service ជាមួយផ្ទៃធំ — application, API (resource server), tenant, action, rule (ចាស់), connection និង grant។ ការកំណត់រចនាសម្ព័ន្ធខុសណាមួយក្នុងចំណោមពួកវាគឺជា auth bypass។ បញ្ជីត្រួតពិនិត្យនេះគឺជាការត្រួតពិនិត្យ 22 ធាតុនៅទូទាំង application, allowlist callback / logout, token និងការបង្វិល refresh, action ផ្ទាល់ខ្លួន, RBAC, ការរកឃើញភាពមិនធម្មតា និងការតាមដានបន្ត។ ធាតុនីមួយៗអាចផ្ទៀងផ្ទាត់បាននៅក្នុង Auth0 Dashboard ក្នុងរយៈពេលក្រោម 10 នាទី។

សម្រាប់បញ្ជីត្រួតពិនិត្យស្មើគ្នាលើ Clerk, សូមមើល បញ្ជីត្រួតពិនិត្យសុវត្ថិភាព Clerk។ សម្រាប់ផ្ទៃខាងក្រោយអំពីហេតុអ្វីការកំណត់រចនាសម្ព័ន្ធខុសនៃ identity-layer គឺជាចំណុចខ្វាក់ឧបករណ៍ AI, សូមមើល ហេតុអ្វីឧបករណ៍សរសេរកូដ AI ទុកគម្លាតសុវត្ថិភាព។

ប្រភេទកម្មវិធី និងប្រភេទ grant

ប្រភេទកម្មវិធី និងប្រភេទ grant ដែលបើកគឺជាការកំណត់ដែលមានផលប៉ះពាល់ខ្ពស់បំផុតនៅក្នុង Auth0។ ការទទួលបានពួកវាខុសបើកថ្នាក់នៃការវាយប្រហារដែលគ្មានកូដ frontend ណាមួយនឹងបិទឡើយ។

  1. ប្រើ Application Type = Single Page Application សម្រាប់កម្មវិធី browser-only និង Regular Web Application សម្រាប់កម្មវិធី server-rendered។ ប្រភេទខុសអនុញ្ញាតប្រភេទ grant ខុស — ឧទាហរណ៍ Regular Web App ជាមួយ SPA grant បើក Implicit flow ដែលគ្មាន PKCE ដែលលេចធ្លាយ token តាមរយៈ URL fragment។
  2. បិទប្រភេទ Implicit grant លើ application នីមួយៗ។ Dashboard → Application → Advanced Settings → Grant Types → ដោះធីក Implicit។ Implicit flow ត្រឡប់ token នៅក្នុង URL fragment, កន្លែងដែលពួកវាត្រូវបាន log នៅក្នុងប្រវត្តិ browser និង analytics។ ប្រើ Authorization Code with PKCE ជំនួស។
  3. បិទ Password grant លុះត្រាតែអ្នកមានតម្រូវការដែលបានកត់ត្រា។ Resource Owner Password Credentials (ROPC) grant តម្រូវឱ្យអ្នកគ្រប់គ្រង password អ្នកប្រើដោយខ្លួនឯង — បំបាត់ភាគច្រើននៃអ្វីដែលអ្នកទិញ Auth0។ បិទវាលុះត្រាតែបញ្ចូលប្រព័ន្ធចាស់។
  4. បើក Authorization Code with PKCE លើ client សាធារណៈនីមួយៗ។ Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256, OIDC Conformant = បើក។ PKCE ត្រូវការសម្រាប់កម្មវិធី mobile និង SPA ដើម្បីការពារការស្ទាក់ចាប់កូដ។

Allowlist callback និង logout URL

Open redirect នៅលើផ្លូវ callback OAuth គឺជា primitive លួច token។ Allowlist របស់ Auth0 គឺជាការការពារតែមួយរបស់អ្នក។

  1. កំណត់ Allowed Callback URLs ទៅផ្លូវ callback ផលិតកម្មច្បាស់របស់អ្នក — គ្មាន wildcard។ https://yourapp.com/callback, មិនមែន https://yourapp.com/* ឡើយ។ Wildcard callback អនុញ្ញាតឱ្យអ្នកវាយប្រហារ redirect token ទៅ subpath ដែលបង្កើតបាននៅលើ domain របស់អ្នក។
  2. កំណត់ Allowed Logout URLs ទៅបញ្ជីដែលមានកំណត់។ ច្បាប់ដូចគ្នា៖ URL ច្បាស់តែប៉ុណ្ណោះ។ Open logout redirect អនុញ្ញាតឱ្យអ្នកវាយប្រហារបង្កើតទំព័រ phishing ដែលមើលទៅដូចស្ថានភាព post-logout របស់អ្នក។
  3. កំណត់ Allowed Web Origins ទៅ origin ផលិតកម្មរបស់អ្នកតែប៉ុណ្ណោះ។ ប្រើសម្រាប់ authentication ស្ងាត់ (ការ renewal token តាមរយៈ iframe លាក់)។ Origin wildcard អនុញ្ញាតឱ្យទំព័រអ្នកវាយប្រហារធ្វើ auth ស្ងាត់ប្រឆាំងនឹង tenant របស់អ្នក។
  4. កំណត់ Allowed CORS origin សម្រាប់ endpoint API, មិនមែន application។ Tenant Settings → Advanced → Allowed CORS origins។ លំនាំដើមគឺទទេ (រឹតបន្តឹង); បន្ថែម origin ច្បាស់ដែលអ្នកគ្រប់គ្រងតែប៉ុណ្ណោះ។

Token និងការបង្វិល refresh

អាយុ token, ការបង្វិល refresh និង algorithm signing សម្រេចរ៉ាដ្យូស្ផុះនៃការលេចធ្លាយ token ណាមួយ។

  1. បើក Refresh Token Rotation។ Application → Refresh Token Settings → Rotation។ ការ refresh នីមួយៗចេញ refresh token ថ្មី និងបដិសេធចាស់។ រួមជាមួយការផុតកំណត់ absolute, នេះកំណត់ការលួច token។
  2. កំណត់ Refresh Token Reuse Interval ទៅ 0 (ឬទាបបំផុតដែលការអត់ឱន replay របស់អ្នកអនុញ្ញាត)។ Reuse interval អនុញ្ញាតឱ្យ token ត្រូវបានប្រើពីរដងក្នុង window ដូចគ្នា — បិទវាលុះត្រាតែអ្នកមានហេតុផលជាក់លាក់ដើម្បីរក្សាវា។
  3. កំណត់ Absolute Refresh Token Expiry ទៅ 14-30 ថ្ងៃ មិនមែនជាដឹងមិនដឹង។ Application → Refresh Token Expiration → Absolute Expiration។ Auth0 លំនាំដើមទៅ Inactivity-only, ដែលមានន័យថា session ស្ងាត់អាចបន្តរយៈពេលរាប់ឆ្នាំ។
  4. កំណត់ JWT Signature Algorithm ទៅ RS256។ Application → Advanced → OAuth → JsonWebToken Signature Algorithm។ RS256 ប្រើ signing asymmetric ដូច្នេះ client មិនអាចក្លែងបន្លំ token។ មិនដែលប្រើ HS256 សម្រាប់កម្មវិធីដែលប្រឈមមុខ client ឡើយ។
  5. ផ្ទៀងផ្ទាត់ claim aud និង iss លើ JWT នីមួយៗដែល API របស់អ្នកទទួល។ ប្រើ SDK Auth0 ផ្លូវការនៅខាង server — វាផ្ទៀងផ្ទាត់ទាំងនេះដោយស្វ័យប្រវត្តិ។ JWT parsing ដែលធ្វើដោយដៃជារឿយៗរំលងការផ្ទៀងផ្ទាត់ audience ដែលជា auth bypass។

Action និងកូដផ្ទាល់ខ្លួន

Auth0 Action (និង Rule ចាស់) ដំណើរការ server-side ក្នុងពេលចូល និងព្រឹត្តិការណ៍វដ្ដជីវិតផ្សេងទៀត។ ពួកវាមានការចូលប្រើ context request ទាំងមូល។ កូដមិនមានសុវត្ថិភាពនៅទីនេះគឺជាភាពងាយរងគ្រោះទូទាំង tenant។

  1. មិនត្រូវ log event.user ឬ event.transaction ជា object ទាំងមូលឡើយ។ ទាំងនេះមានអាស័យដ្ឋានអ៊ីមែល, អាស័យដ្ឋាន IP និង PII ផ្សេងទៀត។ ប្រើ logging កម្រិត field តែប៉ុណ្ណោះ និង log តែអ្វីដែលអ្នកត្រូវការ។
  2. ប្រើ secrets store សម្រាប់ API key ឬ URL webhook ណាមួយ។ Actions → Edit → Secrets។ មិនដែល inline API key ជា string literal នៅក្នុងកូដ action ឡើយ — កូដនេះអាចមើលឃើញចំពោះនរណាមួយដែលមានការចូលប្រើ Action editor លើ tenant។
  3. ផ្ទៀងផ្ទាត់ input មុនពេលរក្សាពួកវាជា user_metadata ឬ app_metadata។ Action self-service ដែលសរសេរ event.body.name ទៅ user.user_metadata.display_name គឺជាវ៉ិចទ័រ stored-XSS បើ frontend របស់អ្នក render field នោះដោយគ្មាន escaping។

RBAC និង resource server

បើអ្នកប្រើ Auth0 RBAC, ការ mapping role-to-permission គឺជា authorization layer របស់អ្នក។ ទទួលបានវាខុស ហើយអ្នកប្រើ authenticated ណាមួយអាចចូល endpoint admin។

  1. កំណត់ Resource Server (API) ច្បាស់នៅក្នុង Auth0 Dashboard, មិនមែននៅពេលដំណើរការ។ API នីមួយៗមាន identifier (audience), scope និងការកំណត់ signing។ ដោយគ្មាន API ដែលបានចុះឈ្មោះ, token ទាំងអស់ត្រូវបានចេញសម្រាប់ "Auth0 Management API" ដែលបង្កប់ — audience ខុស។
  2. កំណត់រចនាសម្ព័ន្ធ Permission ក្នុង API នីមួយៗ និងតម្រូវឱ្យពួកវាក្នុងកូដរបស់អ្នកជាមួយ claim scope។ មិនត្រូវត្រួតពិនិត្យសមាជិកភាព role ក្នុងតក្កកម្មវិធីរបស់អ្នក; ត្រួតពិនិត្យ scope ក្នុង access token។ Scope គឺជាយន្តការ authorization ដើមកំណើតរបស់ OAuth។
  3. សាកល្បងថាអ្នកប្រើ authenticated ដោយគ្មាន role / scope ដែលត្រូវការមិនអាចចូល endpoint មានសិទ្ធិឡើយ។ ចូលជាអ្នកប្រើធម្មតា, ព្យាយាមហៅ POST /api/admin/users/delete។ Response ត្រូវជា 403។

ការរកឃើញភាពមិនធម្មតា និង log tenant

Auth0 បញ្ចេញព្រឹត្តិការណ៍សញ្ញាខ្ពស់។ កំណត់ពួកវាដើម្បីដាស់តឿនក្រុមរបស់អ្នក មិនមែនគ្រាន់តែអង្គុយក្នុង log buffer។

  1. បើក Attack Protection៖ Bot Detection, Brute Force, Suspicious IP Throttling។ Dashboard → Security → Attack Protection។ មួយៗបិទតាមលំនាំដើមនៅកម្រិតឥតគិតថ្លៃ; បើកពួកវាទាំងអស់សម្រាប់ផលិតកម្ម។
  2. ផ្ទេរ log tenant ទៅ SIEM ឬ log កម្មវិធីរបស់អ្នក។ Dashboard → Monitoring → Streams។ Auth0 រក្សា log 30 ថ្ងៃលើ plan ភាគច្រើន; ការរក្សារយៈពេលវែងតម្រូវឱ្យមាន stream ចូលក្នុងប្រព័ន្ធផ្ទាល់របស់អ្នក។
  3. ដាស់តឿនលើ spike fcoa (បរាជ័យ cross-origin auth) និង fp (បរាជ័យចូល)។ ការផ្ទុះនៃទាំងនេះក្នុង window ខ្លីគឺ credential stuffing។ បញ្ជូនទៅឆានែល on-call របស់អ្នក។

ជំហានបន្ទាប់

ដំណើរការ FixVibe scan ប្រឆាំងនឹង URL ផលិតកម្មរបស់អ្នក — ការត្រួតពិនិត្យ baas.clerk-auth0 សម្គាល់ Auth0 client secret ដែល bundled ក្នុង JavaScript និងថ្នាក់ការបង្ហាញ identity-provider ផ្សេងទៀត។ សម្រាប់ស្មើគ្នាលើ Clerk, សូមមើល បញ្ជីត្រួតពិនិត្យសុវត្ថិភាព Clerk។ សម្រាប់ទិដ្ឋភាពទូទៅនៅទូទាំង BaaS provider, សូមអាន BaaS misconfiguration scanner។

// scan ផ្ទៃ baas របស់អ្នក

រកតារាងបើកចំហមុនពេលនរណាម្នាក់ផ្សេងទៀតរកឃើញ។

បញ្ចូល URL ផលិតកម្ម។ FixVibe រាប់ផ្គូផ្គង BaaS provider ដែលកម្មវិធីរបស់អ្នកនិយាយជាមួយ, fingerprint endpoint សាធារណៈរបស់ពួកគេ និងរាយការណ៍អ្វីដែល client មិនបាន authenticate អាចអាន ឬសរសេរ។ ឥតគិតថ្លៃ, គ្មានការដំឡើង, គ្មានកាត។

  • កម្រិតឥតគិតថ្លៃ — 3 scans/ខែ, គ្មានកាតចុះឈ្មោះ។
  • BaaS fingerprinting បែប passive — មិនត្រូវការការផ្ទៀងផ្ទាត់ domain។
  • Supabase, Firebase, Clerk, Auth0, Appwrite និងច្រើនទៀត។
  • AI fix prompt លើ finding នីមួយៗ — បិទភ្ជាប់ត្រឡប់ទៅក្នុង Cursor / Claude Code។
ដំណើរការ BaaS scan ឥតគិតថ្លៃ →

មិនត្រូវការការចុះឈ្មោះ

បញ្ជីត្រួតពិនិត្យសុវត្ថិភាព Auth0៖ 22 ធាតុ — Docs · FixVibe