How to Secure Firebase Realtime Database with Rules

When you create a Realtime Database, Firebase sets it to either test mode (all reads and writes allowed for 30 days) or locked mode (all reads and writes denied). Both are temporary starting points. Test mode rules expire after 30 days and lock your database completely. Locked mode blocks all client access. You must write custom rules before going to production. Open the Firebase Console, navigate to Realtime Database, and click the Rules tab to see your current rules.

1// DEFAULT TEST MODE (DANGEROUS - expires and allows all access)
2{
3  "rules": {
4    ".read": true,
5    ".write": true
6  }
7}
8
9// DEFAULT LOCKED MODE (blocks everything)
10{
11  "rules": {
12    ".read": false,
13    ".write": false
14  }
15}

The most basic security rule requires users to be signed in before accessing any data. Use the auth variable, which is non-null when a user is authenticated with Firebase Auth. Set .read and .write to auth !== null at the root level. This blocks all unauthenticated access while allowing any signed-in user to read and write any data.

1{
2  "rules": {
3    ".read": "auth !== null",
4    ".write": "auth !== null"
5  }
6}

For user-specific data, structure your database with user IDs as keys and write rules that match the auth.uid against the path variable. This ensures each user can only read and write their own data. Use the $uid wildcard variable to capture the user ID from the path and compare it against auth.uid.

1{
2  "rules": {
3    "users": {
4      "$uid": {
5        ".read": "auth !== null && auth.uid === $uid",
6        ".write": "auth !== null && auth.uid === $uid"
7      }
8    },
9    "posts": {
10      "$postId": {
11        ".read": "auth !== null",
12        ".write": "auth !== null && (!data.exists() || data.child('authorId').val() === auth.uid)"
13      }
14    }
15  }
16}

Use .validate rules to enforce data integrity. Validate that required fields exist, values have the correct type, strings meet length requirements, and numbers fall within expected ranges. Validate rules are checked on writes only and must pass for the write to succeed. Unlike .read and .write, .validate rules do not cascade down the tree, so you need to add them at each specific node.

1{
2  "rules": {
3    "users": {
4      "$uid": {
5        ".read": "auth !== null && auth.uid === $uid",
6        ".write": "auth !== null && auth.uid === $uid",
7        ".validate": "newData.hasChildren(['name', 'email'])",
8        "name": {
9          ".validate": "newData.isString() && newData.val().length > 0 && newData.val().length <= 100"
10        },
11        "email": {
12          ".validate": "newData.isString() && newData.val().matches(/^[^@]+@[^@]+\.[^@]+$/)"
13        },
14        "age": {
15          ".validate": "newData.isNumber() && newData.val() >= 0 && newData.val() <= 150"
16        },
17        "$other": {
18          ".validate": false
19        }
20      }
21    }
22  }
23}

Store user roles in the database (for example, under /roles/{uid}) and reference them in your rules using root.child(). This pattern lets you create admin, moderator, and regular user roles. Admins can read and write all data, while regular users have limited access. You can also use Firebase Auth custom claims for role-based access, which are available in auth.token.

1{
2  "rules": {
3    "roles": {
4      "$uid": {
5        ".read": "auth !== null && auth.uid === $uid",
6        ".write": "auth !== null && root.child('roles/' + auth.uid + '/admin').val() === true"
7      }
8    },
9    "content": {
10      "$contentId": {
11        ".read": "auth !== null",
12        ".write": "auth !== null && (root.child('roles/' + auth.uid + '/admin').val() === true || root.child('roles/' + auth.uid + '/editor').val() === true)"
13      }
14    },
15    "admin_panel": {
16      ".read": "auth !== null && root.child('roles/' + auth.uid + '/admin').val() === true",
17      ".write": "auth !== null && root.child('roles/' + auth.uid + '/admin').val() === true"
18    }
19  }
20}

When you use orderByChild() queries on the client, add .indexOn rules at the parent path to create database indexes. Without indexes, the Realtime Database loads all child nodes and sorts them on the server, which is slow for large datasets. The .indexOn rule tells Firebase to maintain an index for the specified child keys.

1{
2  "rules": {
3    "posts": {
4      ".indexOn": ["createdAt", "authorId"],
5      "$postId": {
6        ".read": "auth !== null",
7        ".write": "auth !== null && auth.uid === newData.child('authorId').val()"
8      }
9    },
10    "messages": {
11      "$roomId": {
12        ".indexOn": ["timestamp", "senderId"]
13      }
14    }
15  }
16}

Before deploying, test your rules using the Rules Playground in the Firebase Console. Go to Realtime Database > Rules tab and click the Simulator button (or Rules Playground). Select the operation type (read, write, set), enter the path, optionally provide authenticated user details, and run the simulation. The playground shows whether the operation is allowed or denied and highlights which rule made the decision.

Save your rules in a database.rules.json file in your project root and deploy them using the Firebase CLI. This lets you version control your rules alongside your application code. Make sure your firebase.json file points to the rules file. Deploy only the database rules without affecting other services using the --only flag.

1// In firebase.json, reference the rules file:
2// {
3//   "database": {
4//     "rules": "database.rules.json"
5//   }
6// }
7
8// Deploy rules only:
9// firebase deploy --only database