// docs / baas security / auth0 hardening
قائمة التحقق لأمان Auth0: 22 بندًا
Auth0 منصة هوية-كخدمة بسطح ضخم — التطبيقات، وAPIs (خوادم الموارد)، والمستأجرون، والإجراءات، والقواعد (قديمة)، والاتصالات، والمنح. التهيئة الخاطئة لأي منها تجاوز للمصادقة. هذه القائمة عبارة عن مراجعة من 22 بندًا عبر التطبيقات، وقوائم سماح callback / logout، والرموز ودوران التحديث، والإجراءات المخصصة، وRBAC، واكتشاف الشذوذ، والمراقبة المستمرة. كل بند قابل للتحقق في لوحة تحكم Auth0 في أقل من 10 دقائق.
للقائمة المكافئة على Clerk، راجع قائمة التحقق لأمان Clerk. للخلفية حول لماذا تكون تهيئات طبقة الهوية الخاطئة نقاط عمياء لأدوات الذكاء الاصطناعي، راجع لماذا تترك أدوات البرمجة بالذكاء الاصطناعي ثغرات أمنية.
نوع التطبيق وأنواع المنح
نوع التطبيق وأنواع المنح المُفعَّلة هي أعلى الإعدادات تأثيرًا في Auth0. الحصول عليها بشكل خاطئ يفتح فئات هجوم لا يمكن لأي قدر من كود الواجهة الأمامية إغلاقها.
- استخدم Application Type = Single Page Application للتطبيقات في المتصفح فقط وRegular Web Application للتطبيقات المُعرضة على الخادم. النوع الخاطئ يسمح بأنواع منح خاطئة — مثلًا، Regular Web App مع منحة SPA يُمكِّن تدفق Implicit بدون PKCE، الذي يُسرِّب الرموز عبر شظايا URL.
- عطِّل نوع منحة Implicit في كل تطبيق. Dashboard → Application → Advanced Settings → Grant Types → اضغط لإلغاء Implicit. تدفق Implicit يُعيد الرموز في شظايا URL، حيث تُسجَّل في تاريخ المتصفح والتحليلات. استخدم Authorization Code مع PKCE بدلًا من ذلك.
- عطِّل منحة Password ما لم يكن لديك حاجة موثَّقة. منحة Resource Owner Password Credentials (ROPC) تتطلب منك التعامل مع كلمات مرور المستخدمين بنفسك — مما يُفقد معظم ما اشتريت Auth0 من أجله. عطِّلها ما لم تتكامل مع نظام قديم.
- فعِّل Authorization Code مع PKCE على كل عميل عام. Dashboard → Advanced Settings → OAuth → JsonWebToken Signature Algorithm = RS256، OIDC Conformant = enabled. PKCE مطلوب لتطبيقات الجوال وSPAs لمنع اعتراض الكود.
قوائم سماح عناوين URL لـ callback و logout
إعادات التوجيه المفتوحة على مسار OAuth callback هي أساس سرقة الرموز. قائمة سماح Auth0 هي دفاعك الوحيد.
- اضبط Allowed Callback URLs على مسار callback إنتاجك الدقيق — بدون بطاقات برية.
https://yourapp.com/callback، لاhttps://yourapp.com/*. عناوين callback ببطاقات برية تسمح للمهاجمين بإعادة توجيه الرموز إلى مسارات فرعية عشوائية على نطاقك. - اضبط Allowed Logout URLs على قائمة محدودة. نفس القاعدة: عناوين URL صريحة فقط. إعادة توجيه logout مفتوحة تسمح للمهاجمين بصياغة صفحات تصيد تبدو كحالة ما بعد تسجيل الخروج لديك.
- اضبط Allowed Web Origins على أصل الإنتاج فقط. يُستخدم للمصادقة الصامتة (تجديد الرمز عبر iframe مخفي). أصل ببطاقة برية يسمح لصفحات المهاجمين بإجراء مصادقة صامتة على مستأجرك.
- اضبط Allowed CORS origins لنقاط نهاية API، لا التطبيق. Tenant Settings → Advanced → Allowed CORS origins. الافتراضي فارغ (مقيَّد)؛ أضف فقط أصولًا صريحة تتحكم بها.
الرموز ودوران التحديث
عمر الرمز ودوران التحديث وخوارزمية التوقيع تقرر دائرة تأثير أي تسرب رمز.
- فعِّل Refresh Token Rotation. Application → Refresh Token Settings → Rotation. كل تحديث يُصدر رمز تحديث جديدًا ويُبطل القديم. مدمجًا مع انتهاء صلاحية مطلق، يحتوي هذا سرقة الرمز.
- اضبط Refresh Token Reuse Interval على 0 (أو منخفضًا قدر ما يسمح به تسامحك للإعادة). فترة إعادة الاستخدام تسمح باستخدام الرمز مرتين في نفس النافذة — أوقفه ما لم يكن لديك سبب محدد لإبقائه.
- اضبط Absolute Refresh Token Expiry على 14-30 يومًا، لا اللانهاية. Application → Refresh Token Expiration → Absolute Expiration. يُعيِّن Auth0 افتراضيًا Inactivity فقط، مما يعني أن جلسة خاملة يمكن أن تستمر لسنوات.
- اضبط JWT Signature Algorithm على RS256. Application → Advanced → OAuth → JsonWebToken Signature Algorithm. RS256 يستخدم توقيعًا غير متماثل بحيث لا يستطيع العميل تزوير الرموز. لا تستخدم أبدًا HS256 للتطبيقات الموجهة للعميل.
- تحقق من ادعاءات
audوissعلى كل JWT يستلمه API الخاص بك. استخدم Auth0 SDK الرسمي على جانب الخادم — يتحقق منها تلقائيًا. تحليل JWT يدوي يتخطى عادةً التحقق من الجمهور، وهو تجاوز للمصادقة.
الإجراءات والكود المخصص
تعمل إجراءات Auth0 (والقواعد القديمة) على الخادم عند تسجيل الدخول وأحداث دورة الحياة الأخرى. لديها وصول إلى سياق الطلب الكامل. الكود غير الآمن هنا هو ثغرة على مستوى المستأجر بأكمله.
- لا تُسجِّل أبدًا
event.userأوevent.transactionككائن كامل. تحتوي هذه على عناوين البريد الإلكتروني وعناوين IP ومعلومات شخصية أخرى. استخدم تسجيل على مستوى الحقل فقط، وسجِّل ما تحتاجه فقط. - استخدم مخزن الأسرار لأي مفتاح API أو URL webhook. Actions → Edit → Secrets. لا تُضمِّن أبدًا مفتاح API كسلسلة حرفية في كود الإجراء — الكود مرئي لأي شخص لديه وصول محرر الإجراء على المستأجر.
- تحقق من المدخلات قبل حفظها كـ user_metadata أو app_metadata. إجراء خدمة ذاتية يكتب
event.body.nameإلىuser.user_metadata.display_nameهو ناقل XSS مخزَّن إذا كانت واجهتك الأمامية تُعرض ذلك الحقل دون هروب.
RBAC وخوادم الموارد
إذا كنت تستخدم Auth0 RBAC، فتعيين الدور إلى الأذونات هو طبقة التفويض لديك. اخطئها وأي مستخدم مُصادق يستطيع الوصول إلى نقاط النهاية الإدارية.
- عرِّف خوادم الموارد (APIs) صراحة في لوحة تحكم Auth0، لا أثناء التشغيل. كل API له معرِّف (الـ
audience)، ونطاقات، وإعدادات توقيع. بدون API مُسجَّل، تُصدر جميع الرموز للمدمج "Auth0 Management API" — جمهور خاطئ. - كوِّن الأذونات لكل API واطلبها في كودك بادعاء
scope. لا تتحقق من عضوية الدور في منطق تطبيقك؛ تحقق من النطاقات في رمز الوصول. النطاقات هي آلية التفويض الأصلية لـ OAuth. - اختبر أن مستخدمًا مُصادقًا بدون الدور / النطاق المطلوب لا يستطيع الوصول إلى نقاط النهاية المميزة. سجِّل الدخول كمستخدم عادي، وحاول استدعاء
POST /api/admin/users/delete. يجب أن تكون الاستجابة403.
اكتشاف الشذوذ وسجلات المستأجر
يُصدر Auth0 أحداثًا عالية الإشارة. كوِّنها لتنبيه فريقك، لا فقط لتجلس في مخزن سجل.
- فعِّل Attack Protection: Bot Detection، Brute Force، Suspicious IP Throttling. Dashboard → Security → Attack Protection. كل منها مُعطَّل افتراضيًا على المستويات المجانية؛ شغِّلها جميعًا للإنتاج.
- دفِّق سجلات المستأجر إلى SIEM أو سجلات تطبيقك. Dashboard → Monitoring → Streams. يحتفظ Auth0 بالسجلات لمدة 30 يومًا في معظم الخطط؛ الاحتفاظ طويل الأمد يتطلب دفقًا إلى نظامك الخاص.
- تنبيه عند ارتفاع
fcoa(failed cross-origin auth) وfp(failed login). دفعة من هذه في نافذة قصيرة هي حشو بيانات اعتماد. وجِّه إلى قناة المناوبة الخاصة بك.
الخطوات التالية
شغِّل مسح FixVibe على عنوان URL الإنتاج — فحص baas.clerk-auth0 يُؤشِّر أسرار عميل Auth0 المُدمَّجة في JavaScript وفئات كشف موفِّر الهوية الأخرى. للمكافئ على Clerk، راجع قائمة التحقق لأمان Clerk. للحصول على رؤية شاملة عبر موفِّري BaaS، اقرأ ماسح التهيئة الخاطئة لـ BaaS.
