إرشادات الأمان العامة لبيئات سير عمل التطوير المختلفة
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
توضح هذه الصفحة أهم الممارسات المتعلقة بالأمان عبر
البيئات، ولكن راجع
قائمة التحقق من الأمان للحصول على
إرشادات شاملة حول الأمان وFirebase.
الأمان في بيئات ما قبل الإنتاج
تتمثل إحدى مزايا فصل البيئات في مشروعات Firebase المختلفة في
لن يتمكن أي شخص ضار يمكنه الوصول إلى بيئات ما قبل الإنتاج
الوصول إلى بيانات المستخدم الحقيقية. في ما يلي أهم الاحتياطات الأمنية التي يجب اتخاذها
لبيئات ما قبل الإنتاج:
تقييد الوصول إلى بيئات ما قبل الإنتاج. بالنسبة إلى التطبيقات المتوافقة مع الأجهزة الجوّالة، استخدِم App Distribution (أو رمز مشابه) لتوزيع التطبيق على مجموعة محدّدة من المستخدمين. يصعب تقييد تطبيقات الويب؛
ننصحك بإعداد
وظيفة الحظر
لبيئات ما قبل الإنتاج التي تفرض قيودًا على الوصول إلى المستخدمين الذين لديهم بريد إلكتروني
للعناوين الخاصة بنطاقك. أو، إذا كنت تستخدم
Firebase Hosting، يمكنك إعداد سير عمل ما قبل الإنتاج لاستخدامه
عناوين URL للمعاينة المؤقتة.
عندما لا تحتاج بيئة إلى الاحتفاظ بها ويتم استخدامها من قبل شخص واحد فقط
شخص (أو بواسطة جهاز واحد في حالة الاختبارات) يستخدم
Firebase Local Emulator Suite ألعاب المحاكاة هذه أكثر أمانًا
وأسرع لأنها تتيح العمل بشكل كامل على المضيف المحلي بدلاً من استخدام السحابة
الموارد.
تأكَّد من إعداد Firebase Security Rules في البيئات التي تخصّ مرحلة ما قبل الإنتاج، تمامًا كما تفعل في مرحلة الإنتاج. بشكل عام، يجب أن يكون Rules متطابقًا في جميع البيئات، مع العِلم أنّه بما أنّ القواعد تتغيّر مع
الرمز البرمجي، قد تكون هناك قواعد في مرحلة سابقة من عملية التطوير لم يتمّ طرحها بعد في مرحلة
الإنتاج.
الأمان لبيئات الإنتاج
تكون بيانات الإنتاج دائمًا هدفًا، حتى إذا كان التطبيق غير واضح. لا يؤدي اتّباع هذه
الإرشادات إلى جعل الحصول على بياناتك من قِبل الجهات الضارة مستحيلاً، ولكنه يجعل ذلك أكثر صعوبة:
تفعيل وفرض App Check لجميع المنتجات
التي تستخدمها والتي تدعمه. يتأكد App Check من أن الطلبات إلى
خدمات الخلفية من تطبيقاتك الحقيقية. من أجل استخدامها،
يجب تسجيل كل إصدار من إصدارات تطبيقك في App Check. من الأسهل
قم بإعداده قبل أن يكون لديك مستخدمين، لذا قم بإعداده في أقرب وقت ممكن.
اكتب نصًا مميّزًا Firebase Security Rules. تعتمد التطبيقات Realtime Database وCloud Firestore و
Cloud Storage جميعها على Rules الذي يضبطه المطوّر لتحديد مَن يمكنه الوصول إلى البيانات ومَن لا يمكنه ذلك. من الضروري
عن أمنك أنك تكتبه بشكل جيد Rules. إذا لم تكن متأكدًا من كيفية القيام بذلك،
يمكنك البدء من هذا الدرس التطبيقي حول الترميز.
يمكنك مراجعة قائمة التحقّق من الأمان للتعرّف على مزيد من المعلومات.
توصيات حول الأمان لبيئات الإنتاج.
الخطوات التالية
إنّ محتوى هذه الصفحة مرخّص بموجب ترخيص Creative Commons Attribution 4.0 ما لم يُنصّ على خلاف ذلك، ونماذج الرموز مرخّصة بموجب ترخيص Apache 2.0. للاطّلاع على التفاصيل، يُرجى مراجعة سياسات موقع Google Developers. إنّ Java هي علامة تجارية مسجَّلة لشركة Oracle و/أو شركائها التابعين.
تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-25 (حسب التوقيت العالمي المتفَّق عليه)"],[],[],null,["This page describes the most important best practices for security across\nenvironments, but review the\n[*Security checklist*](/support/guides/security-checklist) for more detailed and\nthorough guidance about security and Firebase.\n\nSecurity for pre-production environments\n\nOne benefit of separating environments in different Firebase projects is that a\nmalicious actor who is able to access your pre-prod environments won't be able\naccess real user data. Here are the most important security precautions to take\nfor pre-production environments:\n\n- Limit access to pre-prod environments. For mobile apps, use\n [App Distribution](/docs/app-distribution) (or something similar) to distribute\n an app to a specific set of people. Web applications are harder to restrict;\n consider setting up a\n [blocking function](https://cloud.google.com/identity-platform/docs/blocking-functions)\n for the pre-prod environments that restricts access to users with email\n addresses that are specific to your domain. Or, if you're using\n Firebase Hosting, set up your pre-prod workflows to use\n [temporary preview URLs](/docs/hosting/test-preview-deploy).\n\n- When an environment doesn't need to be persisted and is only being used by one\n person (or in the case of tests, by one machine) use the\n [Firebase Local Emulator Suite](/docs/emulator-suite). These emulators are safer\n and faster because they can work entirely on localhost instead of using cloud\n resources.\n\n- Make sure that you have [Firebase Security Rules](/docs/rules) set up in pre-production\n environments, just as you do in prod. In general, the Rules should\n be the same across environments, with the caveat that since rules change with\n code, there may be rules earlier in the pipeline that don't yet exist in\n production.\n\nSecurity for production environments\n\nProduction data is always a target, even if the app is obscure. Following these\nguidelines doesn't make it impossible for a malicious actor to get your data,\nbut it makes it more difficult:\n\n- Enable and enforce [App Check](/docs/app-check) for all the products\n you're using that support it. App Check makes sure that requests to your\n backend services are coming from your genuine apps. In order to use it, you\n need to register each version of your app with App Check. It's easier to\n set up before you have users, so set it up as soon as possible.\n\n- Write robust [Firebase Security Rules](/docs/rules). Realtime Database, Cloud Firestore, and\n Cloud Storage all rely on developer-configured Rules to\n enforce who should and shouldn't be able to access data. It's essential to\n your security that you write good Rules. If you're not sure how,\n start with this [codelab](/codelabs/firebase-rules).\n\n- Review the [*Security checklist*](/support/guides/security-checklist) for more\n recommendations about security for production environments.\n\nNext steps\n\n- Review the [Firebase launch checklist](/support/guides/launch-checklist)."]]
