// docs / baas security / umbrella scanner
ماسح التهيئة الخاطئة لـ BaaS: اعثر على مسارات البيانات العامة قبل المستخدمين
موفِّرات Backend-as-a-Service — Supabase وFirebase وClerk وAuth0 وAppwrite وConvex — جميعها تفشل أمنيًا بنفس الشكل: تُصدر المنصة افتراضيات معقولة، يطلب المطور (أو أداة البرمجة بالذكاء الاصطناعي) اختصارًا، ويفتح مسار عام بين مهاجم غير مُصادق وبيانات العميل. ماسح التهيئة الخاطئة لـ BaaS هو الأداة الوحيدة التي تستكشف ذلك المسار من الخارج بالطريقة التي قد يفعلها المهاجم. يُحدِّد هذا المقال فئات التهيئة الخاطئة الخمس المتكررة، ويشرح كيف يعمل مسح FixVibe الشامل لـ BaaS، ويُقارن الموفِّرين الأربعة الرئيسيين، ويُقارن الماسح المدرك لـ BaaS بأدوات DAST العامة.
لماذا تأخذ تهيئات 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 مفقود
Clerk webhooks, Stripe webhooks, Supabase webhooks all sign their payloads. A handler that doesn't verify the signature is a database-write primitive for any attacker who guesses the URL.
كيف يعمل مسح FixVibe الشامل لـ BaaS
تعمل مرحلة BaaS في FixVibe في ثلاث مراحل، كل واحدة تُنتج نتائج متميزة:
- Stage 1 — find the providers. FixVibe loads the deployed app and identifies which BaaS providers it talks to — Supabase, Firebase, Clerk, Auth0 and others — from the configuration the browser receives.
- Stage 2 — provider checks. For each provider found, FixVibe runs that provider's checks: open Supabase tables, open Firebase rules, Clerk and Auth0 key exposure, and service-tier credentials in the bundle. Each provider is checked independently — a Supabase finding doesn't block the Firebase scan.
- المرحلة 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 يقوم بعمل محدد لا تقوم به الأدوات الأخرى. المقارنة:
| الجانب | FixVibe (DAST مُدرك لـ BaaS) | DAST عام (Burp / ZAP) | SAST / SCA (سنيك / سيمغريب) |
|---|---|---|---|
| تغطية BaaS | فحوصات أصلية لـ Supabase وFirebase وClerk وAuth0 وAppwrite | زحف ويب عام؛ لا فحوصات خاصة بالموفِّر | تحليل ساكن للمستودع فقط؛ لا تحقق من الإنتاج |
| وقت الإعداد | URL → run → results usually in under a minute | ساعات: كوِّن العنكبوت والمصادقة والنطاق | يوم: تكامل مع CI للمستودع |
| ما يثبته | كشف وقت تشغيل الإنتاج بأدلة على مستوى HTTP | ثغرات تطبيق ويب (XSS، SQLi)؛ BaaS عبر تكوين يدوي | أنماط كود قد تُنشر أو لا تُنشر |
| فحص حزمة JavaScript | Every shipped chunk, with provider-aware key detection | محدود — grep قائم على السلاسل فقط | نعم، ولكن فقط من جانب المستودع، لا المنشور |
| مسح مستمر | شهريًا / عند النشر عبر API + MCP | يدوي؛ كوِّن الجدول الزمني بنفسك | لكل التزام (جيد للكود، أعمى لوقت التشغيل) |
| السعر للفرد / الفريق الصغير | Free plan; paid plans for active and repo scans | Burp Suite Professional is paid (Community Edition is free); ZAP is free and open source | Snyk and Semgrep both offer free tiers; paid tiers add scale |
Where a BaaS scan fits
A BaaS-aware scan checks what your live app exposes. Pair it with FixVibe's GitHub repo scans or another code scanner for source and dependency issues, and with a manual penetration test before a major launch or compliance audit.
الأسئلة الشائعة
هل يعمل المسح الشامل إذا كان تطبيقي يستخدم موفِّري BaaS (مثلًا، Supabase + Clerk)؟
نعم — بصمات الموفِّر والفحوصات لكل موفِّر مستقلة. يكتشف الماسح كليهما، ويُشغِّل مجموعتي الفحوصات، ويُبلِّغ عن الروابط عبر الموفِّرين (مثلًا، قالب JWT لـ Supabase من Clerk يشحن email كادعاء إلى جانب RLS مفقود).
كيف يختلف هذا عن تشغيل Burp Suite Pro على تطبيقي؟
Burp هو ورشة عمل DAST عامة. خارج الصندوق، Burp لا يعرف ما هو PostgREST أو Firestore أو مسار callback لـ Auth0 — عليك تكوين النطاق يدويًا، وكتابة الإضافات، وتفسير الاستجابات. يأتي FixVibe بفحوصات BaaS مدمجة وتنسيق أدلة بشكل BaaS. Burp يتفوق في تغطية تطبيقات الويب العامة (XSS، SQLi، منطق الأعمال)؛ FixVibe يتفوق في نتائج خاصة بـ BaaS.
ماذا عن App Check (Firebase) أو الإثبات (Apple / Google)؟
App Check يجعل عمليات المسح الخارجية الانتهازية تُرجع 403 في كل فحص — النتيجة الصحيحة لروبوت ضار. مسح FixVibe من عميل غير مُثبَت يتصرف بنفس الطريقة. إذا كان لديك App Check مُفعَّل ولا يزال FixVibe يُبلِّغ عن نتائج، فهذا يعني أن قواعدك مفتوحة للعملاء المُثبَتين أيضًا، وهو الخطر الحقيقي. App Check + قواعد صحيحة هو نمط الدفاع في العمق.
هل يمكن للماسح التحقق من إصلاحي؟
Yes — re-run after applying the fix. Findings keep the same identity across runs, so a finding that was open in run 1 and absent in run 2 is proof the fix landed.
الخطوات التالية
شغِّل مسح FixVibe مجاني على عنوان URL الإنتاج — تأتي فحوصات مرحلة BaaS مع كل خطة، بما في ذلك الطبقة المجانية. للتعمقات الخاصة بالموفِّر، تُغطي المقالات الفردية في هذا القسم كل موفِّر بالتفصيل: Supabase RLS وكشف مفتاح Supabase الخدمي وتخزين Supabase وقواعد Firebase وFirebase if-true وClerk وAuth0.