Ensuring third party cannot read data in our Firebase Realtime Database

Question

I'm looking into authentication for Firebase Realtime database and have a few questions which I cannot seem to find an answer for.

We have a Firebase realtime database consisting of a bunch of data which should be accessible for all our users. however, it should only be accessible through our mobile applications and preferably without the need for user registration and login. The users are not going to write to the database, it is only the reading part we are worried about. We do not want someone "copying" our entire database through a script/application.

This question is quite similar to Restrict Firebase database access to one Android app and Firebase Read Only With No Authentication from App. In those discussions, it is suggested to use anonymous authentication https://firebase.google.com/docs/auth/web/anonymous-auth.

If I understand anonymous authentication correctly, it will not solve the issue. Anyone could connect to the same Firebase url from their own script/application with the use of Firebase SDK and just sign in anonymously. This will allow them to read all our data.

Even with the integration of user login e.g. Facebook or Google, our data will still be at great risk of being compromised. Anyone could create a user in our application. Afterwards they could create their own Firebase script/application and connect to our database with that user and retrieve the data.

The discussion Restrict Firebase database access to one Android app talks about possible solutions for restricting access to only the mobile application. This could be done by either using an API key or username/password combination for the app. This would then either be hard coded in the app or send through a service. As stated in the discussion, hard coding seems both hacky and insecure due to decompilation and it will be hard to update in the future if the username/password combination should change for some reason. Sending the API key through a service is also insecure since anyone could request the service from the outside. As mentioned in How to prevent other access to my firebase, there is no way to protect the url.

Is this achievable or am I missing something?

Answer 1

What you want cannot be achieved with Firebase Realtime Database (or, in general with any given public database API).

If you don't require users to present a unique form of identification (e.g. per-user authentication), then the only alternative is to authenticate with some form of secret presented by your app. Of course, as you note, if the secret is presented with your app, then anyone with a copy of your app could extract the secret and use it.

It might be easier to think about the database in a purer form -- just as its REST endpoint.

Effectively, if the rules are configured to allow anyone to read, then anyone can access that URL. But any secret you present is just going to be some extension on that URL (or as an HTTP header). Anyone who knows how to access your database could then just use those same credentials in another context, outside of your app.

Likewise, even if you were to use a Cloud Function or other server-side application code to mediate all accesses to the database via the admin API (and effectively set the security rules to private), you still have the same problem again -- how does your function know that it is "your app" vs some other code impersonating your app? The best you might be able to do is some form of rate limiting to the API in this case, but nothing prevents full extraction of the data.

Another example: Google probably doesn't want anyone to fully download their entire search index, but they want access to the index to be effectively public and anonymous -- they can only really control this via rate limits and allowing very specific operations against the index in server-side code, they never allow you to just dump the entire database. Likewise, they do not expose "more interesting" parts of the data (such as ranking data) to end users directly at all -- only allowing server side code access and using that to generate the results.

Finally, even if you had per-user authentication, nothing prevents those users from, using their own credentials, effectively copying the database if they have the permission to see the whole thing other than carefully written server-side code. In this scenario, however, you could at least do more accurate rate limiting and detection of abuse, by tying the activity to a particular user (and using server-side code to do that detection).