للحفاظ على أمان موارد Firebase وبيانات المستخدمين، اتّبِع الإرشادات التالية. قد لا ينطبق كل عنصر على متطلباتك، ولكن يجب مراعاة هذه المتطلبات أثناء تطوير تطبيقك.
تجنُّب الزيارات المسيئة
إعداد ميزة المراقبة والتنبيهات لخدمات الخلفية
لرصد الزيارات المسيئة، مثل هجمات حجب الخدمة (DoS)، يمكنك إعداد ميزة المراقبة والتنبيهات في Cloud Firestore، Realtime Database، Cloud Storage، Hosting.
إذا كنت تشتبه في تعرُّض تطبيقك لهجوم، يُرجى التواصل مع فريق الدعم في أقرب وقت ممكن لإعلامه بما يحدث.
تفعيل App Check
للمساعدة في التأكّد من أنّ تطبيقاتك فقط هي التي يمكنها الوصول إلى خدمات الخلفية، فعِّل ميزة Firebase App Check لكل خدمة تتيح ذلك.
ضبط Cloud Functions لتوسيع نطاقه ليناسب عدد الزيارات العادي
يتم توسيع نطاق Cloud Functions تلقائيًا لتلبية متطلبات تطبيقك، ولكن في حال حدوث هجوم، قد يؤدي ذلك إلى ارتفاع فاتورة الدفع. لمنع حدوث ذلك، يمكنك حصر عدد النُسخ المتزامنة للوظيفة استنادًا إلى عدد الزيارات العادية لتطبيقك.
إعداد التنبيهات لتلقّي إشعارات عند الاقتراب من بلوغ الحدود القصوى
إذا كانت خدمتك تتلقّى عددًا كبيرًا من الطلبات، سيتم غالبًا تطبيق الحصص، ما يؤدي إلى تقليل عدد الزيارات إلى تطبيقك تلقائيًا. احرص على مراقبة لوحة بيانات الاستخدام والفوترة، ويمكنك أيضًا ضبط تنبيهات بشأن الميزانية في مشروعك لتلقّي إشعارات عند تجاوز استخدام الموارد التوقعات.
منع عمليات حجب الخدمة الذاتية: اختبار الوظائف على الجهاز باستخدام المحاكيات
من السهل أن تُوقِف نفسك عن العمل عن طريق الخطأ أثناء التطوير Cloud Functions: على سبيل المثال، من خلال إنشاء حلقة كتابة بدء لا نهائية. يمكنك منع هذه الأخطاء من التأثير في الخدمات المنشورة من خلال تنفيذ عملية تطوير باستخدام Firebase Local Emulator Suite.
وإذا حدث ذلك عن طريق الخطأ، يمكنك إلغاء نشر الدالة من خلال حذفها
من index.js ثم تشغيل
firebase deploy --only functions
عندما تكون الاستجابة في الوقت الفعلي أقل أهمية، تعمل البنية بشكل دفاعي
إذا لم تكن بحاجة إلى عرض نتيجة دالة في الوقت الفعلي، يمكنك الحدّ من الزيارات المسيئة من خلال معالجة النتائج بشكل مجمّع: يمكنك نشر النتائج في موضوع Pub/Sub ، ومعالجة النتائج على فترات منتظمة باستخدام دالة مجدوَلة.
فهم مفاتيح واجهة برمجة التطبيقات
مفاتيح واجهة برمجة التطبيقات لخدمات Firebase ليست سرية
لا تستخدم Firebase مفاتيح واجهة برمجة التطبيقات إلّا لتحديد مشروع Firebase الخاص بتطبيقك لخدمات Firebase، وليس للتحكّم في الوصول إلى قاعدة البيانات أو بيانات Cloud Storage، ويتم ذلك باستخدام Firebase Security Rules. لهذا السبب، لستَ بحاجة إلى التعامل مع مفاتيح واجهة برمجة التطبيقات لخدمات Firebase على أنّها سرية، ويمكنك تضمينها بأمان في رمز العميل. اطّلِع على مزيد من المعلومات عن مفاتيح واجهة برمجة التطبيقات في Firebase.
ضبط القيود المفروضة على مفتاح واجهة برمجة التطبيقات
كإجراء وقائي إضافي ضد المهاجم الذي يحاول استخدام مفتاح واجهة برمجة التطبيقات بهدف انتحال هوية الطلبات، يمكنك إضافة قيود مفاتيح واجهة برمجة التطبيقات لحصر مفاتيح واجهة برمجة التطبيقات في عملاء تطبيقك وواجهات برمجة التطبيقات التي تستخدمها.
الحفاظ على سرية مفاتيح خادم FCM
على عكس مفاتيح واجهة برمجة التطبيقات لخدمات Firebase، فإنّ مفاتيح خادم FCM (التي تستخدمها واجهة برمجة التطبيقات FCM HTTP API القديمة) حسّاسة ويجب الحفاظ على سريتها.
الحفاظ على سرية مفاتيح حسابات الخدمة
وعلى عكس مفاتيح واجهة برمجة التطبيقات لخدمات 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 وإضافتها إلى عملية التطوير المتكامل (CI)
للتأكّد من أنّ قواعد الأمان تتماشى مع تطوير تطبيقك، اختبِر قواعدك على مستوى الوحدة باستخدام IDE Firebase Local Emulator Suite وأضِف هذه الاختبارات إلى مسار عملية التطوير المتكامل (CI). اطّلِع على هذين الدليلَين المتعلّقين بتطبيقَي 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 (إجراء يُنصح به) لتطوير التطبيق، قد لا تحتاج إلى منح إذن وصول أوسع إلى مشروع الإصدار العلني.
إدارة المكتبة
الانتباه إلى الأخطاء الإملائية في المكتبة أو المشرفين الجدد
عند إضافة مكتبات إلى مشروعك، انتبه جيدًا إلى اسم المكتبة ومشرفيها. قد تحتوي مكتبة تحمل اسمًا مشابهًا للمكتبة التي تريد تثبيتها على رمز ضار.
عدم تعديل المكتبات بدون فهم التغييرات
اطّلِع على سجلّات التغييرات في أي مكتبات تستخدمها قبل الترقية. تأكَّد من أنّ الترقية تضيف قيمة، وتحقّق من أنّ الجهة التي تدير الإصدار ما زالت جهة تثق بها.
تثبيت مكتبات watchdog كموارد تطوير أو اختبار
استخدِم مكتبة مثل Snyk لفحص مشروعك بحثًا عن التبعيات غير الآمنة.
إعداد ميزة "التتبّع" لـ Cloud Functions، والاطّلاع عليها بعد تحديثات المكتبة
إذا كنت تستخدم حزمة SDK لتسجيل Cloud Functions، يمكنك مراقبة السلوك غير المعتاد والتحذير منه ، بما في ذلك السلوك الناتج عن تحديثات المكتبة.