ماسح التهيئة الخاطئة لـ BaaS: اعثر على مسارات البيانات العامة قبل المستخدمين

لماذا تأخذ تهيئات BaaS الخاطئة شكلًا متكررًا

كل منصة BaaS تتبع نفس الهندسة المعمارية: خلفية مُدارة مع SDK عميل رفيع يتحدث إليها من المتصفح. يحتاج العميل الموجه للمتصفح إلى بعض بيانات الاعتماد — مفتاح anon، مفتاح قابل للنشر، معرِّف مشروع Firebase — لتعريف نفسه للخلفية. هذه بيانات الاعتماد عامة بشكل مقصود؛ تعتمد سلامة الهندسة على ضوابط الوصول على مستوى المنصة (RLS، القواعد، قوائم السماح) القيام بعملها.

تبني أدوات البرمجة بالذكاء الاصطناعي فوق هذه الهندسة دون استيعاب طبقة ضوابط المنصة. تربط SDK العميل بشكل صحيح، وتقبل قواعد المنصة الافتراضية المتساهلة (التي توجد لصداقة الدروس)، وتُطلق. الشكل المتكرر هو: بيانات اعتماد عامة + قاعدة افتراضية متساهلة + تجاوز مفقود = كشف بيانات. فئات التهيئة الخاطئة الخمس أدناه كلها متغيرات من هذا الشكل.

فئات التهيئة الخاطئة الخمس المتكررة

تظهر هذه عبر كل موفِّر BaaS. يغطي المسح الكامل جميع الخمس مقابل كل موفِّر مستخدم:

الفئة 1: مفتاح خاطئ في حزمة المتصفح

يشحن المتصفح المفتاح السري/المسؤول (Supabase service_role، مفتاح Firebase Admin SDK الخاص، Clerk sk_*، سر عميل Auth0) بدلًا من المكافئ العام/anon. يصبح المتصفح عميل مسؤول غير مقيَّد. مغطى بـ فحص أسرار الحزمة من FixVibe.

الفئة 2: طبقة التحكم في الوصول مُعطَّلة أو متساهلة

RLS مُعطَّل، قواعد Firebase if true، قائمة callback في Auth0 ببطاقات برية. بيانات الاعتماد في المتصفح هي الصحيحة — ولكن الحدود على مستوى المنصة التي كان من المفترض أن تقيدها لا تقوم بعملها.

الفئة 3: قراءات مجهولة لموارد حساسة

مجموعات Firestore قابلة للقراءة المجهولة، دلاء تخزين Supabase قابلة للسرد المجهول، API إدارة Auth0 قابل للوصول المجهول. يسأل المسح: "بدون بيانات اعتماد، ماذا يمكنني قراءته؟"

الفئة 4: أثار الوضع التجريبي في الإنتاج

مفاتيح تجريبية (pk_test_* وsb_test_*) في نشر إنتاج؛ تطبيقات Firebase في وضع التطوير قابلة للوصول من النطاق الحي؛ تطبيقات Auth0 لمستأجر تجريبي بإعدادات أضعف من الإنتاج. يقارن المسح مفاتيح وقت التشغيل بالبادئات المتوقعة للإنتاج.

الفئة 5: التحقق من توقيع webhook مفقود

webhooks Clerk وStripe وSupabase جميعها توقِّع حمولاتها. معالج لا يتحقق من التوقيع هو أساس كتابة قاعدة بيانات لأي مهاجم يخمن URL. يُكتشف عبر شكل الاستجابة — طلب غير موقَّع يحصل على 200 يعني تخطي التحقق.

كيف يعمل مسح FixVibe الشامل لـ BaaS

تعمل مرحلة BaaS في FixVibe في ثلاث مراحل، كل واحدة تُنتج نتائج متميزة:

1. <strong>Stage 1 — provider fingerprinting.</strong> The scanner crawls the deployed app, parses every JavaScript chunk, and identifies which BaaS providers the app uses. Each provider has a distinctive runtime signature: Supabase uses <code>*.supabase.co</code>; Firebase uses <code>firebase.initializeApp({ projectId: ... })</code>; Clerk uses <code>pk_*</code> keys with a known prefix; Auth0 uses <code>clientId</code> and <code>domain</code>. The scanner records which providers are present and extracts the project identifiers.
2. المرحلة 2 — فحوصات خاصة بالموفِّر. لكل موفِّر مُكتشف، يُشغِّل الماسح الفحص الخاص بالموفِّر: baas.supabase-rls يستكشف PostgREST؛ baas.firebase-rules يستكشف Firestore + RTDB + Storage؛ baas.clerk-auth0 يتحقق من بادئة المفاتيح المُدمَّجة؛ فحص أسرار الحزمة يتحقق من عدم تسرب أي بيانات اعتماد على مستوى الخدمة. يعمل كل فحص بشكل مستقل — نتيجة Supabase لا تحجب مسح Firebase.
3. المرحلة 3 — ربط عبر الموفِّرين. يُربط الماسح بين النتائج. مفتاح Supabase service-role مُسرَّب إلى جانب RLS مفقود هو أكثر خطورة من أي نتيجة بمفردها — يُسلِّط التقرير الضوء على هذا. موفِّرو هوية متعددون (Clerk + Auth0 + مصادقة مخصصة) في نفس التطبيق هو نتيجة بنيوية مُؤشَّرة للمراجعة.

كل فحص سلبي: قراءة مجهولة واحدة على الأكثر لكل مورد، مع تسجيل شكل الاستجابة ولكن محتويات الصفوف لا تُقسَّم على صفحات أو تُخزَّن أبدًا. فحوصات الكتابة والتعديل مشروطة بالتحقق من ملكية النطاق — لا تُشغَّل أبدًا على أهداف غير مُتحقَّق منها.

ما يجده الماسح لكل موفِّر

لكل موفِّر BaaS سطح مختلف واستراتيجية مسح مختلفة. إليك ما هو مغطى:

• Supabase: RLS مفقود على الجداول، دلاء تخزين قابلة للسرد المجهول، JWT service_role مُسرَّب أو مفتاح sb_secret_* في الحزمة، مخططات مكشوفة عبر سرد OpenAPI مجهول. راجع ماسح Supabase RLS وقائمة التحقق للتخزين.
• Firebase: قواعد if true على Firestore وRealtime Database وCloud Storage؛ دلاء Storage قابلة للسرد المجهول؛ فرض App Check مفقود. راجع ماسح قواعد Firebase وشرح قاعدة if-true.
• Clerk: مفاتيح سرية sk_* مُدمَّجة، pk_test_* في الإنتاج، التحقق من توقيع webhook مفقود، أصول مسموح بها ببطاقات برية. راجع قائمة التحقق لـ Clerk.
• Auth0: أسرار عميل مُدمَّجة، منحة Implicit مُفعَّلة، عناوين URL لـ callback / logout ببطاقات برية، PKCE مفقود على SPAs. راجع قائمة التحقق لـ Auth0.

كيف يُقارَن ماسح BaaS بأدوات DAST وSAST العامة

ماسح مُدرك لـ BaaS يقوم بعمل محدد لا تقوم به الأدوات الأخرى. المقارنة:

نطاق صادق: ما لا يحل محله هذا الماسح

ماسح DAST مُدرك لـ BaaS أداة مُركَّزة، ليس برنامج أمان كامل. لا يقوم بـ:

• استبدال SAST أو SCA. يجد التحليل الساكن CVEs للتبعيات (Snyk، Semgrep) وثغرات على مستوى الكود (SonarQube) لا يستطيع ماسح DAST اكتشافها. شغِّل كليهما.
• استبدال اختبار الاختراق اليدوي. يجد مختبر الاختراق البشري عيوب منطق الأعمال، وحالات حافة التفويض، والثغرات المتسلسلة التي لا يستطيع أي ماسح اكتشافها. استأجر مختبر اختراق قبل إطلاق كبير أو مراجعة امتثال.
• مراجعة الكود أو المستودع للأسرار في تاريخ git. فحص أسرار الحزمة يُغطي ما هو منشور حاليًا، لا ما تم الالتزام به تاريخيًا. استخدم git-secrets أو gitleaks لنظافة المستودع.
• تغطية خدمات الخلفية غير BaaS. إذا كان تطبيقك يستخدم خلفية مخصصة (Express، Rails، Django، FastAPI)، يمسح FixVibe سطح HTTP الخاص بها ولكنه لا يستكشف قاعدة البيانات أو البنية التحتية وراءها. هذا منطقة DAST + SAST العامة.

الأسئلة الشائعة

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

شغِّل مسح FixVibe مجاني على عنوان URL الإنتاج — تأتي فحوصات مرحلة BaaS مع كل خطة، بما في ذلك الطبقة المجانية. للتعمقات الخاصة بالموفِّر، تُغطي المقالات الفردية في هذا القسم كل موفِّر بالتفصيل: Supabase RLS وكشف مفتاح Supabase الخدمي وتخزين Supabase وقواعد Firebase وFirebase if-true وClerk وAuth0.