Firebase allow read, write: if true مشروحًا: ما يفعله وكيفية إصلاحه

البنية، سطرًا بسطر

وثيقة قواعد كاملة للوضع التجريبي لـ Firestore هي ستة أسطر:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

مفكوكة:

• rules_version = '2'; يختار محرك القواعد v2 (الحالي). قواعد v1 الأقدم مهجورة.
• service cloud.firestore يحصر الكتلة على Firestore. Realtime Database يستخدم بنية مختلفة قائمة على JSON؛ Cloud Storage يستخدم service firebase.storage.
• match /databases/{database}/documents يربط قاعدة البيانات الخاصة (default) (معظم المشاريع تحتوي على واحدة فقط).
• match /{document=**} هي بطاقة برية متكررة. ** تطابق أي مسار بأي عمق. مدمجة مع {document}، تلتقط كل وثيقة في كل مجموعة — جملة مطابقة واحدة تحكم قاعدة البيانات بأكملها.
• allow read, write: if true; هو نص القاعدة. يُسمح بكل من read وwrite؛ الشرط if true هو، حسنًا، صحيح دائمًا. read يُغطي عمليتي get وlist؛ write يُغطي create وupdate وdelete.

الأثر الصافي: أي عميل يحمل معرِّف مشروع Firebase وSDK المناسب يمكنه قراءة أو كتابة أي وثيقة في أي مجموعة. المصادقة غير مطلوبة. حدود المعدل غير مفروضة.

لماذا يُصدِر Firebase هذا كافتراضي

يريد Firebase أن تكون مبرمجًا خلال أول 30 ثانية بعد إنشاء مشروع. البديل — إجبارك على كتابة قاعدة صحيحة قبل أن تعمل أي قراءة أو كتابة — سيُعيق التهيئة الأولية. لذا تقدم وحدة التحكم خيارين عند إنشاء قاعدة بيانات: Production mode (رفض كل شيء، أنت تكتب القواعد) أو Test mode (السماح بكل شيء لمدة 30 يومًا). معظم المطورين ينقرون على الوضع التجريبي، ثم ينسون العودة. كانت المشاريع القديمة بمؤقت 30 يومًا؛ المشاريع الحالية بقاعدة if true غير محدودة دون انتهاء صلاحية تلقائي.

المشكلة البنيوية: تتدرب أدوات البرمجة بالذكاء الاصطناعي على التوثيق والدروس وإجابات Stack Overflow التي تُظهر قواعد الوضع التجريبي. عندما تسأل Cursor أو Claude Code "كيف أُعدّ Firebase"، تشمل الإجابة كثيرًا كتلة allow read, write: if true الدقيقة كأنها قاعدة الإنتاج. لا يعرف الذكاء الاصطناعي — ولا يتم تنبيهه ليعرف — أن هذه القاعدة غير آمنة للإنتاج.

ما يراه المهاجم

بشكل ملموس، يمكن لمهاجم يعرف معرِّف مشروع Firebase الخاص بك (قابل للاستخراج من أي حزمة تطبيق منشور خلال 30 ثانية) ويُشغِّل ما يلي سرد كل وثيقة في كل مجموعة:

طلب curl واحد غير مُصادق كافٍ لتعداد كل مجموعة. راجع الكتلة المُميَّزة أدناه.

curl 'https://firestore.googleapis.com/v1/projects/[project-id]/databases/(default)/documents:listCollectionIds' \
  -X POST \
  -H 'Content-Type: application/json' \
  -d '{}'

الاستجابة هي القائمة الكاملة للمجموعات من المستوى الأعلى. لكل مجموعة، يُعيد طلب ثانٍ الوثائق. لا يوجد حد للمعدل على هذا المسار لأن قواعد if true تقبل حركة المرور المجهولة. لقد رأينا قواعد بيانات Firebase تحتوي على ملايين الوثائق تم تعدادها في أقل من ساعة.

في مسار الكتابة: POST واحد مع {fields} يُنشئ وثيقة جديدة. يمكن للمهاجمين تلويث مجموعاتك بقمامة، أو تشويه الصفحات الموجهة للمستخدم التي تقرأ من Firestore، أو استخدام قاعدة بياناتك كوسيط رسائل مجاني — ترتفع فاتورة استخدامك، وتحقق، وتشرح الفاتورة المشكلة.

أربعة بدائل آمنة للإنتاج

اختر البديل الذي يطابق نموذج بيانات تطبيقك. الأربعة جميعًا تفترض أن لديك مصادقة مستخدم (Firebase Auth أو أي موفِّر يُصدر رمز معرِّف Firebase):

الخيار 1: وثائق مملوكة للمستخدم

النمط الأكثر شيوعًا لـ SaaS. تعيش الوثائق تحت /users/{userId}/... وفقط المالك يمكنه لمسها. match /users/{userId}/{document=**} { allow read, write: if request.auth != null && request.auth.uid == userId; }

match /users/{userId}/{document=**} {
  allow read, write: if request.auth != null
                     && request.auth.uid == userId;
}

الخيار 2: حقل مالك على كل وثيقة

عندما تعيش الوثائق في مجموعات مسطحة (لا متداخلة تحت معرِّف المستخدم)، خزِّن حقل owner_uid وتحقق منه. match /posts/{postId} { allow read: if resource.data.public == true || resource.data.owner_uid == request.auth.uid; allow write: if request.auth.uid == resource.data.owner_uid; }

match /posts/{postId} {
  allow read:  if resource.data.public == true
              || resource.data.owner_uid == request.auth.uid;
  allow write: if request.auth.uid == resource.data.owner_uid;
}

الخيار 3: عزل المؤسسات متعددة المستأجرين

لـ B2B SaaS ببيانات محصورة بالمؤسسة. خزِّن حقل org_id على كل وثيقة وتحقق منه مقابل ادعاء مخصص للمستخدم. allow read, write: if request.auth.token.org_id == resource.data.org_id;. يتطلب تعيين الادعاء المخصص أثناء التسجيل عبر Firebase Admin SDK.

allow read, write: if request.auth.token.org_id == resource.data.org_id;

الخيار 4: محتوى عام للقراءة فقط

للمحتوى التسويقي، والملفات الشخصية العامة، وكتالوجات المنتجات — أي شيء قابل للقراءة عام حقًا ولكن قابل للكتابة من المسؤول فقط. match /products/{productId} { allow read: if true; allow write: if request.auth.token.admin == true; }. يُعيَّن الادعاء المخصص admin على حسابات المسؤولين فقط.

match /products/{productId} {
  allow read:  if true;
  allow write: if request.auth.token.admin == true;
}

استعلام مراجعة سريع

قبل الإصلاح، تحقق مما إذا كانت if true حية فعلًا. افتح وحدة تحكم Firebase → Firestore → Rules وابحث عن if true. إذا وجدتها في أي مكان خارج تعليق، فلديك نتيجة قاعدة مفتوحة. يتيح لك محاكي القواعد في نفس الواجهة إعادة تشغيل طلب المهاجم محليًا — الصق GET /users/somebody مجهول وأكِّد أن المحاكي يُعيد Allowed.

تأكيد خارجي: شغِّل مسح FixVibe على عنوان URL الإنتاج. فحص baas.firebase-rules يستكشف قواعد Firestore وRealtime Database وStorage الخاصة بك ويُبلِّغ عن نفس النتيجة التي قد يكتشفها المهاجم — مستقلًا عما تُظهره وحدة تحكم Firebase.

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

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

شغِّل مسح FixVibe على عنوان URL الإنتاج — يُؤكِّد فحص baas.firebase-rules ما إذا كانت if true قابلة للاستغلال حاليًا من الإنترنت العام. لآليات الماسح والاكتشافات الموازية لـ Realtime Database وStorage، راجع ماسح قواعد Firebase. لفئة التهيئة الخاطئة المكافئة على Supabase، اقرأ ماسح Supabase RLS.