// docs / baas security / clerk hardening

قائمة التحقق لأمان Clerk: 20 بندًا

يتولى Clerk المصادقة والجلسات والمؤسسات لتطبيقك — مما يعني أن تكاملًا خاطئًا لـ Clerk هو تجاوز للمصادقة، أو ناقل تثبيت جلسة، أو مسار تسريب للمؤسسة. هذه القائمة عبارة عن مراجعة من 20 بندًا عبر المفاتيح، وتكوين الجلسة، وwebhooks، والمؤسسات، وقوالب JWT، والمراقبة المستمرة. تربط أدوات البرمجة بالذكاء الاصطناعي Clerk بسرعة بإعدادات افتراضية معقولة؛ هذه القائمة تلتقط البنود التي تتركها على الطاولة.

للخلفية حول لماذا تكون تهيئات طبقة المصادقة الخاطئة نقطة ضعف لأدوات الذكاء الاصطناعي، راجع لماذا تترك أدوات البرمجة بالذكاء الاصطناعي ثغرات أمنية. للقائمة الموازية على Auth0، راجع قائمة التحقق لأمان Auth0.

مفاتيح البيئة وقائمة السماح للأصول

يُصدر Clerk مفتاحين مختلفين لكل مشروع. خلطهما أو تسريبهما هو نمط الفشل الأول.

استخدم المفتاح القابل للنشر (pk_live_* في الإنتاج، pk_test_* في التطوير) في المتصفح؛ استخدم المفتاح السري (sk_live_* / sk_test_*) على الخادم فقط. المفتاح القابل للنشر آمن في NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY؛ المفتاح السري يجب ألا يحمل أبدًا بادئة بيئة عامة ويجب ألا يظهر أبدًا في مكوّن عميل.
تحقق من أن تطبيق الإنتاج يستخدم pk_live_*، لا pk_test_*. تسمح المثيلات التجريبية بعناوين بريد إلكتروني غير مُتحقَّق منها وMFA مُعطَّل — إطلاق الوضع التجريبي إلى الإنتاج هو تجاوز للمصادقة.
كوِّن الأصول المسموح بها في لوحة تحكم Clerk. Settings → Domains → Allowed origins يجب أن يسرد نطاق الإنتاج بدقة. قوائم الأصول الفارغة أو بالبطاقات البرية تسمح للمهاجمين بإنشاء واجهات Clerk مارقة تتحدث إلى خادمك.
دوِّر المفتاح السري عند أي مغادرة أو تسرب مشتبه به. Dashboard → API Keys → Reset. يُبطل المفتاح القديم؛ أعد نشر كود الخادم بالقيمة الجديدة قبل التدوير.

تكوين الجلسة

انتهاء صلاحية الجلسة ومهلات الخمول هي الفرق بين أن تكون جلسة مسروقة حادثة 10 دقائق وحادثة 30 يومًا.

اضبط مهلة خمول الجلسة على 30 دقيقة أو أقل لتطبيقات SaaS التي تتعامل مع بيانات حساسة. Dashboard → Sessions → Inactivity timeout. تطبيقات المستوى المصرفي يجب أن تستخدم 5-10 دقائق؛ SaaS قياسي 30-60 دقيقة؛ تطبيقات المستهلك 1-7 أيام. الافتراضي 7 أيام.
فعِّل إلغاء الجلسة عند تغيير كلمة المرور وتغيير البريد الإلكتروني وتسجيل MFA. Dashboard → Sessions → Revoke on. هذه أحداث أمنية بدأها المستخدم؛ يجب قتل الجلسات الموجودة على الأجهزة الأخرى.
تحقق من الجلسات على الخادم في كل مسار محمي، لا فقط عند تسجيل الدخول. في Next.js: const { userId } = await auth(); في مكوّن خادم / مسار API يقرأ JWT من ملف تعريف الارتباط ويُصادق عليه. لا تثق أبدًا بفحص ملف تعريف ارتباط فقط.
اضبط SameSite=Lax (الافتراضي) أو Strict على ملف تعريف ارتباط الجلسة. تحقق في DevTools → Application → Cookies. SameSite=None ناقل CSRF — لا تستخدمه أبدًا ما لم تكن قد كوَّنت بشكل صريح إعداد مصادقة عبر النطاقات.

التحقق من webhook

تُطلَق webhooks Clerk على أحداث دورة حياة المستخدم (created، updated، deleted، session.ended). إنها آلية المزامنة لقاعدة بياناتك — وwebhook مُزوَّر هو أساس كتابة قاعدة بيانات.

تحقق من توقيع Svix على كل webhook. webhooks Clerk موقَّعة بواسطة Svix. استخدم new Webhook(secret).verify(body, headers). ارفض بـ 401 إذا فشل التحقق.
خزِّن سر webhook في متغير بيئة، لا أبدًا في الكود. يتم تدوير السر عند كل إعادة توليد من لوحة التحكم — يجب على نشرك القراءة من البيئة، لا من ثابت.
عدم تكرار التأثير في كل معالج. يمكن لتسليمات webhook التكرار. استخدم ترويسة svix-id كمفتاح أساسي في جدول webhook_events لإزالة التكرار. غلِّف تغيير الحالة وإدراج عدم التكرار في نفس المعاملة.
عند user.deleted، احذف فعليًا أو أخفِ المعلومات الشخصية خلال 24 ساعة. GDPR / CCPA يتطلبان ذلك. راجع مسار الحذف: ما الجداول التي تحتوي على بيانات هذا المستخدم؟ استخدم FK ON DELETE CASCADE حيث يمكنك.

المؤسسات والأذونات

إذا كنت تستخدم Clerk Organizations، فحدود المؤسسة هي عزل المستأجر. يجب أن يصفي كل استعلام على الخادم به.

في كل مسار API، اقرأ كلًا من userId وorgId من auth() وصفِّ استعلامات قاعدة البيانات بكليهما. WHERE org_id = $orgId AND user_id = $userId. لا تثق أبدًا بـ 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.
اختبر عزل المؤسسات المتقاطع بحسابي مؤسسة حقيقيتين. أنشئ المؤسسة A، واملأها بالبيانات، وسجِّل الدخول إلى المؤسسة B في متصفح آخر، وحاول قراءة بيانات المؤسسة A عبر API. يجب أن تكون الاستجابة 403 أو 404.

قوالب JWT والتكاملات الخارجية

تدفع قوالب JWT هوية Clerk إلى Supabase وFirebase والخدمات اللاحقة الأخرى. القوالب المُهيأة بشكل خاطئ تشارك أكثر من اللازم من الادعاءات أو تكشف بيانات لم تقصد كشفها.

لكل قالب JWT، اسرد كل ادعاء وأكِّد أنه ضروري. Dashboard → JWT Templates. قالب يشحن email وphone إلى Supabase يكشف معلومات شخصية لأي شخص يقرأ JWT في المتصفح.
اضبط انتهاء صلاحية قصير على قوالب JWT المستخدمة للاستدعاءات اللاحقة من جانب العميل. 60 ثانية لطلبات API اللاحقة هو المعيار. JWTs الأطول عمرًا تُسرَق ويُعاد تشغيلها.
تحقق من ادعاء الجمهور (aud) على الجانب المستلم. Supabase وFirebase وغيرها يجب أن تتحقق من أن aud يطابق معرِّف الخدمة المتوقع. بدون ذلك، يمكن لـ JWT صادر لخدمة A المصادقة على الخدمة B.

المراقبة التشغيلية

المصادقة هي أعلى مصدر إشارة لديك. راقبها.

تنبيه عند ارتفاع فشل تسجيل الدخول لكل IP / لكل حساب. معدل فشل 50 ضعفًا للطبيعي هو هجوم حشو بيانات الاعتماد. يُصدر Clerk هذه الأحداث إلى webhooks؛ وجِّهها إلى SIEM الخاص بك.
مراجعة فصلية لانحراف إعدادات الجلسة والمثيل. تتغير الافتراضيات مع تحديثات Clerk؛ "التكوينات القديمة" تصبح خاطئة بصمت بمرور الوقت. قارن تصدير JSON من لوحة التحكم بنسختك الأخيرة المعروفة جيدة.

الخطوات التالية

شغِّل مسح FixVibe على عنوان URL الإنتاج — فحص baas.clerk-auth0 يُؤشِّر مفاتيح Clerk القابلة للنشر، والمفاتيح التجريبية في الإنتاج، والمفاتيح السرية المُدمَّجة. للقائمة المكافئة على Auth0، راجع قائمة التحقق لأمان Auth0. للحصول على رؤية شاملة عبر موفِّري BaaS، اقرأ ماسح التهيئة الخاطئة لـ BaaS.