0

I have a SwiftUI application, which uses Firebase as a back end, and my rules are something like this:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // This rule allows anyone on the internet to view, edit, and delete
    // all data in your Firestore database. It is useful for getting
    // started, but it is configured to expire after 30 days because it
    // leaves your app open to attackers. At that time, all client
    // requests to your Firestore database will be denied.
    //
    // Make sure to write security rules for your app before that time, or else
    // your app will lose access to your Firestore database
    match /{document=**} {
      allow read, write: if request.time < timestamp.date(2020, 10, 28);
    }
  }
}

I understand that these rules allow anyone to read and write to the database. However, as long as they are only using the API provided to the them in the application, how is this insecure? For instance, I could understand the danger, if, say, someone took the xcode project from my laptop and created a button that deleted all users in the database. But, no one will have access to this code.

I do want users to be able to read and write to/from the database, so I was just wondering if these rules are insecure, and, if so why? Like what is an example of how a hacker with malicious intent could exploit these rules to gain unauthorized access to user information and/or somehow modify the database in a way that the API provided in my application does not allow?

Thank you.

Evan
  • 1,892
  • 2
  • 19
  • 40

1 Answers1

1

as long as they are only using the API provided to the them in the application

This is precisely the problem.

Your app contains all the configuration needed to connect to the database (and other resources in your Firebase project). A malicious user can take this configuration data, and call the API themselves - thus bypassing any of your client-side logic.

While you can configure Firebase App Check to help only allow access to the database is coming from your code, that is no guarantee and somebody else's might still use their code with your configuration data.

That's why it's crucial that you also encode your business logic in your security rules. Say that your application code only allows the user to delete their own account from the database, you'll then also want to encode that logic in your security rules so that they're enforced on the server. This is a variation of what the Firebase documentation on securing your database describes as content-owner only access.

Frank van Puffelen
  • 565,676
  • 79
  • 828
  • 807
  • Okay cool thank you for the answer, I'll implement rules similar to those described in the firebase documentation. `A malicious user can take this configuration data, and call the API themselves - thus bypassing any of your client-side logic.` How could they do this? Like how could they get access to the API themselves, without going through the app as it is on the app store? or perhaps that's something I shouldn't worry about, and should just know that it is possible. – Evan Aug 16 '20 at 20:06
  • 1
    They'd (or somebody they know) need your app to get the keys of course. But they can then just extract the configuration data from it. And since your app *needs* this same data to access the project legitimately, there's no way to prevent malicious users from getting it. Hence: server-side security rules are for the moment the only way to address this. – Frank van Puffelen Aug 16 '20 at 20:08
  • hi, thanks for the answer. so, to be sure about this, would something like: `match {document=**} { allow read, write: if request.auth != null; }` prevent malicious users from accessing the database. – Evan Aug 17 '20 at 00:12
  • No it wouldn't, because anyone can get the configuration data from your app and call the API to sign in. Please study the documentation I linked carefully, as it explains it better than I can do here - and has an example of a more secure (and more complex) use-case. – Frank van Puffelen Aug 17 '20 at 02:26
  • Okay thank you very much I will read it over more thoroughly, appreciate the insight. – Evan Aug 17 '20 at 02:27