Firebase RealTime Database Security Rules for personal app

Question

I have created an application in Flutter and I will be the only one to use it since it makes my work easier. It uses Firebase Realtime Database to synchronize data between my devices. When I read the Firebase documentation, I realized I needed to protect my database to prevent access from strangers, so I looked for a way to import some kind of password to pass as a payload when requesting and writing data. But there doesn't seem to be anything like that, I would have to implement Firebase Auth to do that as well. So I opted to create my own dataset with a very particular name, and set the read and write rules only to that particular path. My rules look like this:

{
  "rules": {
    "dataset-verylong32charstringwithalphanumericvalue":{
      ".read": "true",
      ".write": "true",
    }
  }
}

So in theory any other access attempts should be blocked. Since this is a bit of an odd method and not described in the documentation. Can I consider this method safe?

Obviously I know that if some malicious person gets wind of my string they will have full access to my data, but since the chances are low of that happening, I just needed superficial protection against abuse of the service

I have tried making REST requests and all attempts seem to be blocked. So I expect it to be secure. However, I fear there may be a method to map all the paths in my database and then easily derive my string

Answer 1

This is not a safe or efficient method.

If you are the only one who will use this app and can create user accounts, then you could just check if the user is authenticated or not, e.g.

service cloud.firestore {
  match /databases/{database}/documents {
     allow read, write, update, delete: if request.auth != null;
  }
}

If you need to add another layer of security, then you can add custom user claims to the authentication token: https://firebase.google.com/docs/auth/admin/custom-claims

You can then securely access those extra claim fields in the rules (e.g. "request.auth.customField"), and compare them to some other data in your database.

Adding the claims is typically done on a secure backend to keep the Firebase admin details private - but if you are the only user on the frontend app(s), it shouldn't be a security concern to do it on the front end too.

Answer 2

What you're using is known as a shared secret. If it meets your needs then that's a valid way of securing access to the data. There is no way through the client-side SDKs and API to read the root of the database, and thus to learn your secret path that way.

---

For example, download URLs generated by Firebase for Cloud Storage depend on a shared secret to make files publicly readable by everyone who has that secret (it's the token parameter in the URL).

I also used this approach myself when dealing with the data for an events web site. The site was statically regenerated when the data in the database changed, so the shared secret never ended up in the published site.

---

The problem you need to figure out is how you're going to get the shared secret to the consumers of the data. In the above examples we expect either everyone to at possibly get the secret, but then not do any hard (since download URLs are read-only); or we expect only trusted services to know the secret and it never to reach anyone else. If your use-case is different than these, finding a way to share the secret out of band may become your next problem to solve.

---

A simple alternative is to implement anonymous authentication, which allows the app to sign in without requiring any credentials from the user and with a single line of code. With that you can then restrict access to the data to just the UID(s) that you know in your database's security rules. I usually hard-code the UID in the rules, until I get tired of adding/updating them, at which point I switch over to storing an allow-list of them in the database itself.