Naar console

Resolve Insecurities

If you receive an alert that your Firebase Realtime Database is insecure, you can resolve those insecurities by modifying and testing your Realtime Database Rules. Use this guide to check your Realtime Database Rules, understand potential insecurities, and test your changes before deploying them.

Review your Realtime Database Rules

To view your existing Realtime Database Rules, go to the Rules tab in the Firebase console.

Understand your Realtime Database Rules

Realtime Database Rules stand between your data and a malicious user. While it's common to start developing with open rules that allow all users read and write access, it's important to configure your rules to protect your data before you deploy your app. As you're configuring your rules, use the Simulator to test different rules.

If you're new to Realtime Database Rules, learn more about how they work in Get Started with Database Rules.

Resolve common insecurities

The Realtime Database Rules you might have set up by default or as you initially worked on developing your app with Realtime Database might not be the best rules for your deployed app. Take a look at the following common pitfalls and potential resolutions.

Open access

As you set up Realtime Database, you might have set your rules to allow open access during development. If you're the only user with access to your database, this might not seem insecure, but, if you've deployed your app and are not authenticating users, your data is vulnerable to malicious users.

Not recommended: Read and write access to all users
  "rules": {
    ".read": true,
    ".write": true
Solution: Rules that restrict read and write access 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 in User Based Security.

Access for any authenticated user

Sometimes, Realtime Database 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.

Not recommended: Any logged-in user has read and write access to your entire database
  "rules": {
      // any logged-in user access your data
      ".read": "auth !== null",
      ".write": "auth !== null"
Solution: Narrow access using an auth variable 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 auth variable in User Based Security.

Improperly inherited rules

Realtime Database 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.

Not recommended: Refining rules at child paths
  "rules": {
     "foo": {
        // allows read to /foo/*
        ".read": "data.child('baz').val() === true",
        "bar": {
          /* ignored, since read was allowed already */
          ".read": false
Solution: Write rules at parent paths that are broad, and grant more specific privileges at child paths If your data access needs require more granularity, keep your rules granular. Learn more about cascading Realtime Database Rules in Secure Your Data.

Closed access

While you're developing your app, another common approach is to keep your database locked down. Typically, this means you've closed off read and write access to all users, as follows:

  "rules": {
    ".read": false,
    ".write": false

While this isn't insecure, it might also lead to issues when you launch your app. Learn more about configuring and deploying Realtime Database Rules.

Test your Realtime Database Rules

To test your updated Realtime Database Rules, use the Simulator tool in the Firebase console.

  1. To open the Simulator, click Simulator from the Rules tab.
  2. In the Simulator settings, select options for your test, including:
    • Testing reads or writes
    • A specific Location in your database, as a path
    • Authentication type — unauthenticated, authenticated anonymous user, or a specific user ID
  3. Click Run and look for the results in the banner above the rules window.