Firebase Realtime Database xxxx-xxxx-4458' has insecure rules-CodePudding

I am using Firebase Realtime Database for chat functionality in my app. Now we are ready to launch our app so we should fix this issue. xxxx-xxxx-4458' has insecure rules. In official documentation and other places i have found only solution where we need to use firebase auth for validation, But our main database and login process works on our own server and we are using firebase realtime chat as only for chat purpose, so we are not using any firebase authentications so we are still not able to fix issues.

We've detected the following issue(s) with your security rules:

any user can read your entire database
any user can write to your entire database

So Is there is any other way to secure our database without using firebase authentications.

Our Firebase Implementations.

We are using our own server for all the user login,sessions and user data. User login and validate is perform by our own server. That's why we don't use firebase for any other app functions than Real time chat.
As we are not using firebase auth for user validation. It's not possible by us to secure realtime database. User login,registration,sessions,validations all perform by our own server and after validations from our own server then user can start sending message with realtime database.

Our current rules

{
  "rules": {
    ".read": true,
    ".write": true
  }
}

Question: Are we already secured from outsider attack(non-app user). If no then how we can make our database secure in our scenario?.

CodePudding user response：

With your current rules anyone in the world can wipe your database with a single API call. They can also ready all data with a single API call. Neither of those are likely use-cases that your app requires, so I'd say your app is currently not secure.

If you want to properly secure access based on the user identity, you can inform Firebase Authentication of the profile of the user in your own identity system by implementing custom authentication. Once you have that implemented, the auth variable in your security rule will contain the information from your own user system, and you can then use that to secure access to the data.

Even if you know nothing about the user though, you can already secure your app better than what you currently have, by writing rules that fit your use-cases.

For example, since you have a chat app, you likely have a list of chat messages, and users append new messages to this list. Instead of saying that everyone can do whatever they want to the root of your database, you can only allow them to post chat messages with something like:

{
  "rules": {
    "chat": {
      ".read": true,
      "$message_id": {
        ".write": true
      }
    }
  }
}

So now, users can only read the /chat node, and they can only write specific nodes under it. Just this simple change already rules out a whole lot of abuse scenarios.

One step better, would be to validate that the chat messages are of the structure that you expect. For example, if the message have a user name, timestamp, and a text message, that could be:

{
  "rules": {
    "chat": {
      ".read": true,
      "$message_id": {
        ".write": true,
        ".validate": "newData.hasChildren('name', 'timestamp', 'text')"
      }
    }
  }
}

At this point you should note that these rules reflect some of your application code, which is normal: your security rules should only allow what your application code needs, and nothing more. This is known as the principle of least privilege, and is a common security practice.

Finally, you should probably also consider using Firebase App Check which can also prevent a lot of abuse by folks who are not using your application to access the database. Note that this is not a guarantee though, so you'll want to combine App Check for broad protection with security rules for fine-grained control.

Some more resources:

CodePudding user response：

Your current rules allow anyone to read/write to the database. You can either serve the data via your server i.e. using server as middleman to authenticate/authorize users or use custom tokens and sign in users using Firebase authentication. The latter lets you use your existing auth system but also use features of Firebase auth at the same time.