CODEWITHSUNDEEP
firebase-realtime-databasefirebase-authenticationfirebase-security
AlexN
AlexN

Reputation: 51

Firebase authorization and security model

I am making an application that will use Firebase realtime database for distribution of some data. I think my requirements are more or less common.

  1. Few clients with dedicated app written in Java have read/write access.
  2. Many mobile application users have read only access
  3. Anyone else should have problems reading data (well, some problems)
  4. Anyone else should not be able to read some parts of the data
  5. Anyone else should not be able to write data (this is the most important)

While 3 is a desire, 4 is a strong desire, but 5 is an important requirement.

So far I see two approaches to this task

  1. Give read and write access to authorized users, like
    "rules": {
        ".read": "auth.uid !== null",
        ".write": "auth.uid !== null"
      }

Automatically authenticate mobile users with anonymous login, authenticate writers with any other (OAuth) authentication.

  1. Give read access to anyone, write access to authenticated users
    "rules": {
        ".read": "true",
        ".write": "auth.uid !== null"
      }

and encrypt the data or sensitive portions of it.

In any of these methods I see disadvantages. Method 1 is not good, because anyone who can hack the APK will be able to write to the database - this is unacceptable. Also Google will create hundreds or thousands of anonymous accounts for the database - one for each authorization attempt.

Method 2 avoids this, but there is another issue - anyone with good Internet connection will be able to download ALL the data, making me pay huge money to Google. Each terabyte of malicious download will cost me $1000. The only knowledge required to do this is the URL of the database. And in this case I will not be able to do anything, because all clients are already configured for an unrestricted read access.

Are my expectations correct, and what could be the right solution?

Upvotes: 0

Views: 84

Answers (1)

Frank van Puffelen
Frank van Puffelen

Reputation: 598817

Your security rules should reflect precisely what you want your users to allow to do. In that sense they are part of your application code, just like the Java/Kotlin code is that runs on the Android devices.

My preferred model is to evolve my security rules as I'm writing application code.

So I initially grant nobody any access, as I have no code in my app yet that requires access.

Then as I for example write profile data from the app, my security rules reject that write. I modify my rules to allow only the new operation, and nothing else. So: a user can only write their own profile.

Next I may want all signed-in users to read each others' profile, so I write the code for that, which once again gets rejected. And then again, I modify my security rules to allow this specific read operation.

This approach leads to security rules that grant the minimal access that is needed, rather than your approach that tries to implement security as one big toggle for the entire database.

I highly recommend reading the Firebase documentation on security rules, specifically the page that contains some basic use-cases like the one I describe above

Upvotes: 1

Related Questions