للحفاظ على موارد 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) (الذي يستخدمه واجهة برمجة تطبيقات HTTP FCM القديمة) تكون حساسة ويجب الحفاظ على سريتها.
الحفاظ على سرية مفاتيح حساب الخدمة
وعلى عكس مفاتيح واجهة برمجة التطبيقات لخدمات Firebase أيضًا، فإنّ المفاتيح الخاصة لحساب الخدمة (المستخدمة) Firebase Admin SDK) حساسة ويجب الحفاظ على سريته.
Firebase Security Rules
إعداد القواعد في وضع الإنتاج أو وضع القفل
عند إعداد Cloud Firestore وRealtime Database وCloud Storage، عليك إعداد قواعد أمان لرفض جميع عمليات الوصول تلقائيًا، وإضافة قواعد تمنح إمكانية الوصول إلى موارد محددة أثناء تطوير التطبيق.
استخدام أحد الإعدادات التلقائية للمثيلات الجديدة من 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
للتأكّد من أنّ قواعد الأمان لديك تتماشى مع تطوُّر تطبيقك، اختبار الوحدة لقواعدك باستخدام 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 وتُعدّ خيارات موفِّر خدمة الربط (Google وFacebook وغير ذلك) هي الأكثر أمانًا. إِنْتَ مع واحد أو أكثر من مزودي الخدمة هؤلاء إذا أمكنك ذلك (بناءً على المستخدم الأساسية).
المصادقة بكلمة مرور البريد الإلكتروني: تحديد حصة محدودة لنقطة نهاية تسجيل الدخول لمنع هجمات القوة الغاشمة
إذا كنت تستخدم خدمة مصادقة البريد الإلكتروني وكلمة مرور البريد الإلكتروني المُدارة من Firebase، عليك تضييق
الحصة التلقائية لنقاط النهاية identitytoolkit.googleapis.com لمنع عمليات الاختراق
بهجمات القوة. يمكنك القيام بذلك من
صفحة واجهة برمجة تطبيقات مجموعة أدوات الهوية
في وحدة تحكّم 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 لـ 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، ثم يمكنك المراقبة وتلقّي التنبيهات من السلوكيات غير المعتادة، بما في ذلك السلوك الناجم عن تحديثات المكتبة.