Use this guide to understand common vulnerabilities in Firebase Security Rules configurations, review and better secure your own rules, and test your changes before deploying them.
If you receive an alert that your data isn't properly secured, review these commonly made errors and update any vulnerable rules.
Access your Firebase Security Rules
To view your existing Rules , use either the Firebase CLI or the Firebase console. Make sure you edit your rules using the same method, consistently, to avoid mistakenly overwriting updates. If you're not sure whether your locally defined rules reflect the most recent updates, the Firebase console always shows the most recently deployed version of your Firebase Security Rules .
To access your rules from the Firebase console , select your project, then navigate to Realtime Database , Cloud Firestore or Storage. Click Rulesonce you're in the correct database or storage bucket.
To access your rules from the Firebase CLI, go to the rules file noted in your firebase.json file .
Understand Firebase Security Rules
Firebase Security Rules protect your data from malicious users. When you create a database instance or Cloud Storage bucket in the Firebase console, you can choose to either deny access to all users ( Locked mode) or grant access to all users ( Test mode). While you might want a more open configuration during development, make sure you take the time to properly configure your rules and secure your data before deploying your app.
As you're developing your app and testing different configurations for your rules, use one of the local Firebase emulators to run your app in a local development environment.
Common scenarios with insecure rules
The Rules you might have set up by default or as you initially worked on developing your app should be reviewed and updated before you deploy your app. Make sure you properly secure your users' data by avoiding the following common pitfalls.
Open access
As you set up your Firebase project, you might have set your rules to allow open access during development. You might think you're the only person using your app, but if you've deployed it, it's available on the internet. If you're not authenticating users and configuring security rules, then anyone who guesses your project ID can steal, modify, or delete the data.
Cloud Firestore
// Allow read/write access to all users under any conditions // Warning: **NEVER**use this ruleset in production; it allows // anyone to overwrite your entire database. service cloud . firestore { match / databases / { database } / documents { match / { document = ** } { allow read , write : if true ; } } }
Realtime Database
{ // Allow read/write access to all users under any conditions // Warning : ** NEVER ** use this ruleset in production ; it allows // anyone to overwrite your entire database. "rules": { ".read": true, ".write": true } }
Cloud Storage
// Anyone can read or write to the bucket , even non - users of your app . // Because it is shared with App Engine , this will also make // files uploaded using App Engine public . // Warning : This rule makes every file in your Cloud Storage bucket accessible to any user . // Apply caution before using it in production , since it means anyone // can overwrite all your files . service firebase . storage { match / b / { bucket } / o { match / { allPaths =** } { allow read , write ; } } }
Build rules that make sense for your data hierarchy. One of the common solutions to this insecurity is user-based security with Firebase Authentication . Learn more about authenticating users with rules .
Cloud Firestore
Realtime Database
Cloud Storage
Access for any authenticated user
Sometimes, Rules
check that a user is logged in, but don't further
restrict access based on that authentication. If one of your rules includes auth != null
, confirm that you want any logged-in user to have access to the
data.
Cloud Firestore
service cloud . firestore { match /databases/{database } / documents { match /some_collection/{document } { allow read, write : if request . auth . uid != null ; } } }
Realtime Database
{
"rules": {
".read": "auth.uid !== null",
".write": "auth.uid !== null"
}
}
Cloud Storage
// Only authenticated users can read or write to the bucket service firebase . storage { match / b / { bucket } / o { match / { allPaths = ** } { allow read , write : if request . auth ! = null ; } } }
When you're checking for authentication, you might also want to use one of the authentication properties to further restrict access to specific users for specific data sets. Learn more about the different authentication properties .
Cloud Firestore
Realtime Database
Cloud Storage
( Realtime Database ) Improperly inherited rules
Realtime Database Security Rules cascade, with rules at more shallow, parent paths overriding rules at deeper, child nodes. When you write a rule at a child node, remember that it can only grant additional privileges. You can't refine or revoke access to data at a deeper path in your database.
{
"rules": {
"foo": {
// allows read to /foo/*
".read": "data.child('baz').val() === true",
"bar": {
/* ignored, since read was allowed already */
".read": false
}
}
}
}
Closed access
While you're developing your app, another common approach is to keep your data locked down. Typically, this means you've closed off read and write access to all users, as follows:
Cloud Firestore
// Deny read/write access to all users under any conditions service cloud . firestore { match / databases / { database } / documents { match / { document = ** } { allow read , write : if false ; } } }
Realtime Database
{
"rules": {
".read": false,
".write": false
}
}
Cloud Storage
// Access to files through Cloud Storage is completely disallowed. // Files may still be accessible through App Engine or Google Cloud Storage APIs. service firebase . storage { match / b / { bucket } / o { match / { allPaths = ** } { allow read , write : if false ; } } }
The Firebase Admin SDKs and Cloud Functions can still access your database. Use these rules when you intend to use Cloud Firestore or Realtime Database as a server-only backend in conjunction with the Firebase Admin SDK. While it is secure, you should test that your app's clients can properly retrieve data.
Learn more about Cloud Firestore Security Rules and how they work in Get Started with Cloud Firestore Security Rules .
Test your Cloud Firestore Security Rules
To check your app's behavior and verify your Cloud Firestore Security Rules configurations, use the Firebase Emulator . Use the Cloud Firestore emulator to run and automate unit tests in a local environment before you deploy any changes.
To quickly validate Firebase Security Rules in the Firebase console, use the Firebase Rules Simulator .
