General security guidelines for different development workflow environments
Stay organized with collections
Save and categorize content based on your preferences.
This page describes the most important best practices for security across
environments, but review the
Security checklist for more detailed and
thorough guidance about security and Firebase.
Security for pre-production environments
One benefit of separating environments in different Firebase projects is that a
malicious actor who is able to access your pre-prod environments won't be able
access real user data. Here are the most important security precautions to take
for pre-production environments:
Limit access to pre-prod environments. For mobile apps, use
App Distribution (or something similar) to distribute
an app to a specific set of people. Web applications are harder to restrict;
consider setting up a
blocking function
for the pre-prod environments that restricts access to users with email
addresses that are specific to your domain. Or, if you're using
Firebase Hosting, set up your pre-prod workflows to use
temporary preview URLs.
When an environment doesn't need to be persisted and is only being used by one
person (or in the case of tests, by one machine) use the
Firebase Local Emulator Suite. These emulators are safer
and faster because they can work entirely on localhost instead of using cloud
resources.
Make sure that you have Firebase Security Rules set up in pre-production
environments, just as you do in prod. In general, the Rules should
be the same across environments, with the caveat that since rules change with
code, there may be rules earlier in the pipeline that don't yet exist in
production.
Security for production environments
Production data is always a target, even if the app is obscure. Following these
guidelines doesn't make it impossible for a malicious actor to get your data,
but it makes it more difficult:
Enable and enforce App Check for all the products
you're using that support it. App Check makes sure that requests to your
backend services are coming from your genuine apps. In order to use it, you
need to register each version of your app with App Check. It's easier to
set up before you have users, so set it up as soon as possible.
Write robust Firebase Security Rules. Realtime Database, Cloud Firestore, and
Cloud Storage all rely on developer-configured Rules to
enforce who should and shouldn't be able to access data. It's essential to
your security that you write good Rules. If you're not sure how,
start with this codelab.
Review the Security checklist for more
recommendations about security for production environments.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-27 UTC."],[],[],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)."]]