قائمة التحقّق من الأمان في Firebase

للحفاظ على أمان موارد Firebase وبيانات المستخدمين، اتّبِع هذه الإرشادات. قد لا تنطبق بعض العناصر بالضرورة على متطلباتك، ولكن يجب وضعها في الاعتبار أثناء تطوير تطبيقك.

تجنُّب الزيارات المسيئة

إعداد ميزة المراقبة والتنبيه لخدمات الخلفية

لرصد الزيارات المسيئة، مثل هجمات حجب الخدمة (DOS)، عليك إعداد المراقبة والتنبيهات لكل من Cloud Firestore وRealtime Database وCloud Storage وHosting

إذا كنت تشكّ في حدوث هجوم على تطبيقك، يُرجى التواصل مع فريق الدعم في أقرب وقت ممكن لإعلامهم بما يحدث.

تفعيل App Check

للمساعدة في ضمان وصول تطبيقاتك فقط إلى خدمات الخلفية، يمكنك تفعيل Firebase App Check لكل خدمة تتيح ذلك.

ضبط Cloud Functions لتوسيع نطاقه بما يتناسب مع عدد الزيارات العادي

يتم توسيع نطاق Cloud Functions تلقائيًا لتلبية متطلبات تطبيقك، ولكن في حال حدوث هجوم، قد يؤدي ذلك إلى تكلفة كبيرة. لمنع ذلك، يمكنك الحدّ من عدد النُسخ المتزامنة من دالة استنادًا إلى عدد الزيارات العادي لتطبيقك.

إعداد التنبيهات لتلقّي إشعارات عند الاقتراب من الحدود القصوى

إذا كانت خدمتك تشهد ارتفاعات مفاجئة في عدد الطلبات، سيتم غالبًا تفعيل الحصص، وسيتم تلقائيًا تقييد عدد الزيارات إلى تطبيقك.

  • احرص على مراقبة لوحة البيانات الاستخدام والفوترة.

  • يمكنك إعداد تنبيهات بشأن الميزانية لمشروعك ليتم إعلامك عندما يتجاوز استخدام الموارد التوقعات.

  • إذا كنت تستخدم Firebase AI Logic وFirebase App Hosting وCloud Functions for Firebase وFirebase Extensions، يمكنك إعداد حدود الإنفاق لإيقاف الخدمة المعنيّة مؤقتًا إذا وصل مشروعك إلى الميزانية المحدّدة لتلك الخدمة.

منع هجمات حجب الخدمة الذاتية: اختبِر الدوال محليًا باستخدام المحاكيات

قد يكون من السهل أن تحجب الخدمة عن نفسك عن طريق الخطأ أثناء التطوير Cloud Functions: على سبيل المثال، من خلال إنشاء حلقة كتابة مشغّلة لا نهائية. يمكنك منع هذه الأخطاء من التأثير في الخدمات المنشورة من خلال إجراء عملية التطوير باستخدام Firebase Local Emulator Suite.

وإذا تسبّبت عن طريق الخطأ في حجب الخدمة عن نفسك، يمكنك إلغاء نشر الدالة من خلال حذفها من index.js ثم تشغيل firebase deploy --only functions.

في الحالات التي تكون فيها الاستجابة في الوقت الفعلي أقل أهمية، يمكنك هيكلة الدوال بشكل دفاعي

إذا لم تكن بحاجة إلى عرض نتيجة دالة في الوقت الفعلي، يمكنك الحدّ من الزيارات الضارة من خلال معالجة النتائج على دفعات: نشر النتائج في موضوع Pub/Sub ومعالجة النتائج على فترات منتظمة باستخدام دالة مجدوَلة.

التعرّف على مفاتيح واجهة برمجة التطبيقات

مفاتيح واجهة برمجة التطبيقات لخدمات Firebase ليست سرية

تُستخدم مفاتيح واجهة برمجة التطبيقات لخدمات Firebase فقط من أجل تحديد مشروع Firebase وتطبيقك على Firebase لهذه الخدمات. تتم معالجة التفويض من خلال أذونات "إدارة الهوية وإمكانية الوصول" في Google Cloud وFirebase Security Rules وFirebase App Check.

يتم تلقائيًا حصر جميع مفاتيح واجهة برمجة التطبيقات التي توفّرها Firebase على واجهات برمجة التطبيقات ذات الصلة بـ Firebase. إذا كان إعداد تطبيقك يتّبع الإرشادات الواردة في هذه الصفحة، لا يلزم التعامل مع مفاتيح واجهة برمجة التطبيقات المحصورة على خدمات Firebase على أنّها أسرار، ويمكن تضمينها بأمان في الرمز أو ملفات الإعداد.

إعداد قيود مفتاح واجهة برمجة التطبيقات

إذا كنت تستخدم مفاتيح واجهة برمجة التطبيقات لخدمات Google الأخرى، تأكَّد من تطبيق قيود مفاتيح واجهة برمجة التطبيقات لتحديد نطاق مفاتيح واجهة برمجة التطبيقات لعملاء تطبيقك وواجهات برمجة التطبيقات التي تستخدمها.

استخدِم مفاتيح واجهة برمجة التطبيقات التي تم توفيرها من خلال Firebase فقط لواجهات برمجة التطبيقات ذات الصلة بـ Firebase. إذا كان تطبيقك يستخدم أي واجهات برمجة تطبيقات أخرى (مثل Places API لـ "خرائط Google" أو Gemini Developer API)، استخدِم مفتاح واجهة برمجة تطبيقات منفصلاً وقيِّده بواجهة برمجة التطبيقات السارية.

الحفاظ على سرية مفاتيح خادم FCM

على عكس مفاتيح واجهة برمجة التطبيقات لخدمات Firebase، فإنّ مفاتيح خادم FCM (المستخدَمة من خلال واجهة برمجة التطبيقات FCM HTTP القديمة) تتضمّن معلومات حساسة ويجب الحفاظ على سريتها.

تفعيل سجلّ التدقيق في Cloud Messaging

ننصحك بتفعيل تسجيل تدقيق السحابة الإلكترونية لمشروع "Cloud Messaging" لتتمكّن من تسجيل الأنشطة الإدارية وأحداث الوصول ضمن موارد FCM.

الحفاظ على سرية مفاتيح حساب الخدمة

على عكس مفاتيح واجهة برمجة التطبيقات لخدمات Firebase، فإنّ المفاتيح الخاصة لحسابات الخدمة (التي تستخدمها Firebase Admin SDK) تتضمّن معلومات حساسة ويجب الحفاظ على سريتها.

Firebase Security Rules

تهيئة القواعد في وضع الإصدار العلني أو وضع القفل

عند إعداد Cloud Firestore وRealtime Database وCloud Storage، عليك ضبط Firebase Security Rules على رفض جميع عمليات الوصول تلقائيًا، ثم إضافة قواعد تمنح إذن الوصول إلى موارد معيّنة أثناء تطوير تطبيقك.

استخدِم أحد الإعدادات التلقائية للحالات الجديدة من Cloud Firestore (وضع الإنتاج) وRealtime Database (وضع القفل). بالنسبة إلى Cloud Storage، ابدأ بضبط قواعد الأمان على النحو التالي:

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read, write: if false;
    }
  }
}

قواعد الأمان هي مخطط، لذا أضِف القواعد عند إضافة المستندات

لا تكتب قواعد الأمان بعد كتابة تطبيقك، كنوع من المهام التي يجب إكمالها قبل الإطلاق. بدلاً من ذلك، اكتب قواعد الأمان أثناء كتابة تطبيقك، وتعامل معها مثل مخطط قاعدة البيانات: كلما احتجت إلى استخدام نوع مستند جديد أو بنية مسار جديدة، اكتب قاعدة الأمان الخاصة به أولاً.

اختبار قواعد الأمان باستخدام Local Emulator Suite وإضافتها إلى التكامل المستمر

للتأكّد من أنّ قواعد الأمان تواكب عملية تطوير تطبيقك، يمكنك إجراء اختبار وحدة لقواعدك باستخدام Firebase Local Emulator Suite وإضافة هذه الاختبارات إلى مسار التكامل المستمر. يمكنك الاطّلاع على هذين الدليلَين حول Cloud Firestore وRealtime Database.

المصادقة

المصادقة المخصّصة: إنشاء رموز JWT من بيئة موثوق بها (من جهة الخادم)

إذا كان لديك نظام تسجيل دخول آمن، سواء كان نظامًا مخصّصًا أو خدمة تابعة لجهة خارجية، يمكنك استخدام نظامك الحالي للمصادقة مع خدمات Firebase. أنشئ رموز JWT مخصّصة من بيئة موثوقة، ثم مرِّر الرموز المميّزة إلى العميل الذي يستخدم الرمز المميّز للمصادقة (iOS+ وAndroid والويب وUnity وC++‎).

للاطّلاع على مثال على استخدام المصادقة المخصّصة مع موفّر خدمة خارجي، يُرجى مراجعة منشور المدوّنة المصادقة باستخدام Firebase من خلال Okta.

المصادقة المُدارة: مقدّمو خدمات OAuth 2.0 هم الأكثر أمانًا

إذا كنت تستخدم ميزات المصادقة المُدارة في Firebase، ستكون خيارات موفّر خدمة OAuth 2.0 / OpenID Connect (مثل Google وFacebook وما إلى ذلك) هي الأكثر أمانًا. يجب أن تتيح استخدام واحد أو أكثر من مقدّمي الخدمات هؤلاء إذا كان بإمكانك ذلك (حسب قاعدة المستخدمين لديك).

المصادقة باستخدام عنوان البريد الإلكتروني وكلمة المرور: يمكنك ضبط حصة صارمة لنقطة نهاية تسجيل الدخول لمنع هجمات القوة العمياء

إذا كنت تستخدم خدمة المصادقة المُدارة باستخدام البريد الإلكتروني وكلمة المرور في Firebase، عليك تشديد الحصة التلقائية لنقاط النهاية identitytoolkit.googleapis.com لمنع هجمات القوة الغاشمة. يمكنك إجراء ذلك من صفحة Identity Toolkit API في وحدة تحكّم Google Cloud.

مصادقة البريد الإلكتروني وكلمة المرور: تفعيل ميزة "الحماية من تعداد عناوين البريد الإلكتروني"

إذا كنت تستخدم خدمة المصادقة المُدارة عبر البريد الإلكتروني وكلمة المرور في Firebase، فعِّل ميزة "الحماية من تعداد عناوين البريد الإلكتروني"، التي تمنع الجهات المسيئة من إساءة استخدام نقاط نهاية المصادقة في مشروعك لتخمين أسماء الحسابات.

الترقية إلى Google Cloud Identity Platform لاستخدام المصادقة المتعدّدة العوامل

لتعزيز مستوى الأمان عند تسجيل الدخول، يمكنك إضافة ميزة المصادقة المتعدّدة العوامل من خلال الترقية إلى Google Cloud Identity Platform. سيظل رمز Firebase Authentication الحالي صالحًا للاستخدام بعد الترقية.

المصادقة بدون الكشف عن الهوية

استخدام المصادقة المجهولة فقط لإعداد المستخدمين الجدد

استخدِم المصادقة المجهولة فقط لحفظ الحالة الأساسية للمستخدمين قبل تسجيل دخولهم فعليًا. لا تُعدّ المصادقة المجهولة بديلاً عن تسجيل دخول المستخدم.

تحويل المستخدمين إلى طريقة تسجيل دخول أخرى إذا أرادوا الاحتفاظ ببياناتهم على أجهزة أخرى

لن يتم الاحتفاظ ببيانات المصادقة المجهولة الهوية إذا محا المستخدم التخزين المحلي أو بدّل الأجهزة. إذا كنت بحاجة إلى الاحتفاظ بالبيانات بعد إعادة تشغيل التطبيق على جهاز واحد، حوِّل حساب المستخدم إلى حساب دائم.

استخدام قواعد أمان تتطلّب من المستخدمين الانتقال إلى مقدّم خدمة تسجيل الدخول أو تأكيد عنوان بريدهم الإلكتروني

يمكن لأي شخص إنشاء حساب مجهول الهوية في مشروعك. لذلك، ننصحك بحماية جميع البيانات غير المتاحة للجميع من خلال قواعد الأمان التي تتطلّب طرقًا معيّنة لتسجيل الدخول أو عناوين بريد إلكتروني تم التحقّق منها.

على سبيل المثال:

allow write: if request.auth.token.firebase.sign_in_provider != "anonymous";
allow write: if request.auth.token.email_verified = true;

Cloud Functions الأمان

عدم وضع معلومات حساسة في متغيّرات البيئة

غالبًا ما تستخدم في تطبيق Node.js المستضاف ذاتيًا متغيرات البيئة لاحتواء معلومات حساسة مثل المفاتيح الخاصة. لا تفعل ذلك في Cloud Functions. بما أنّ Cloud Functions تعيد استخدام البيئات بين عمليات استدعاء الدوال، يجب عدم تخزين المعلومات الحساسة في البيئة.

  • لتخزين مفاتيح واجهة برمجة التطبيقات في Firebase (وهي ليست سرية)، ما عليك سوى تضمينها في الرمز البرمجي.

  • إذا كنت تستخدم Firebase Admin SDK في Cloud Functions، لن تحتاج إلى تقديم بيانات اعتماد حساب الخدمة بشكل صريح، لأنّ Admin SDK يمكنه الحصول عليها تلقائيًا أثناء الإعداد.

  • إذا كنت تستدعي واجهات برمجة تطبيقات Google وGoogle Cloud التي تتطلّب بيانات اعتماد حساب الخدمة، يمكن لمكتبة Google Auth لـ Node.js الحصول على بيانات الاعتماد هذه من بيانات الاعتماد التلقائية للتطبيق، والتي تتم تعبئتها تلقائيًا في Cloud Functions.

  • لإتاحة المفاتيح الخاصة وبيانات الاعتماد للخدمات غير التابعة لـ Google في Cloud Functions، استخدِم Secret Manager.

تشفير المعلومات الحساسة

إذا لم تتمكّن من تجنُّب تمرير معلومات حسّاسة إلى دوالّك، عليك التوصّل إلى حلّ مخصّص لتشفير المعلومات.

الدوال البسيطة أكثر أمانًا، وإذا كنت بحاجة إلى التعقيد، يمكنك استخدام Cloud Run

حاول أن تجعل دوالك أساسية ومفهومة قدر الإمكان. يمكن أن يؤدي التعقيد في الدوال إلى حدوث أخطاء يصعب رصدها أو سلوك غير متوقّع.

إذا كنت بحاجة إلى منطق معقّد أو إعدادات بيئة، ننصحك باستخدام Cloud Run بدلاً من Cloud Functions.

إدارة البيئة

إعداد مشاريع التطوير والمشاريع المرحلية

إعداد مشاريع Firebase منفصلة للتطوير والتنظيم والإنتاج لا تدمج رمز العميل في قناة الإصدار العلني قبل اختباره في مشروع الإصدار التجريبي.

حصر إذن وصول الفريق إلى بيانات الإصدار العلني

إذا كنت تعمل مع فريق أكبر، يمكنك الحدّ من عواقب الأخطاء والانتهاكات من خلال حصر الوصول إلى بيانات الإنتاج باستخدام أدوار "إدارة الهوية وإمكانية الوصول" المحدّدة مسبقًا أو أدوار "إدارة الهوية وإمكانية الوصول" المخصّصة.

إذا كان فريقك يستخدم Firebase Local Emulator Suite (يُنصح به) للتطوير، قد لا تحتاج إلى منح إذن وصول أوسع إلى مشروع الإنتاج.

إدارة المكتبة

احذر من الأخطاء الإملائية في المكتبات أو المشرفين الجدد

عند إضافة مكتبات إلى مشروعك، انتبه جيدًا إلى اسم المكتبة ومسؤولي الصيانة. قد تحتوي مكتبة تحمل اسمًا مشابهًا للاسم الذي تريد تثبيته على رمز برمجي ضار.

لا تحدِّث المكتبات بدون فهم التغييرات

راجِع سجلّات التغيير لأي مكتبات تستخدمها قبل الترقية. تأكَّد من أنّ الترقية تضيف قيمة، وأنّ الجهة المسؤولة عن الصيانة لا تزال جهة موثوقة.

تثبيت مكتبات المراقبة كموارد تابعة للتطوير أو الاختبار

استخدِم مكتبة مثل Snyk لفحص مشروعك بحثًا عن التبعيات غير الآمنة.

إعداد ميزة الإشراف على حساب Cloud Functions والتحقّق منه بعد تعديل المكتبة

إذا كنت تستخدم حزمة تطوير البرامج (SDK) الخاصة بمسجّل Cloud Functions، يمكنك مراقبة السلوك غير المعتاد وتلقّي تنبيهات بشأنه، بما في ذلك السلوك الناتج عن تحديثات المكتبة.