0

I have a small web-based Flutter application that uses Firebase/Firestore. The security rules are allow read, write;

I got an anonymous email from a (friendly) hacker stating that

  • "Our Firebase database credentials are leaked in response to a request" (??)
  • "He was able to modify the database" (which he did indeed)

I understand that I have virtually no security with the given rules but can somebody explain how a hacker can get access to the database and modify it? I guess the starting point is the network requests that can be seen in the browsers developer console but I have no clue what's next. Can somebody outline how one can modify the Firestore database?

In an attempt to improve this, I have added anonymous authentication to my project and modified the security rules to allow read, write: if request.auth != null;
Does this make hacking attempts (a bit) less easy?

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
Marc Van Daele
  • 2,856
  • 1
  • 26
  • 52

2 Answers2

2

With the allow read, write; security rules, as soon as someone has the API Key of your Firebase Project (which is public and can easily be found in the code of your app) he can read and write to your database, for example by using the Cloud Firestore API.

Modifying your security rules to allow read, write: if request.auth != null; is not necessarily a solution: If the email/password sign-in method is enabled in your Project, one can use the Firebase Auth REST API and sign-up to your project (i.e. create a new account). Once the user is signed-in the request.auth != null expression becomes true.

One classical approach to avoid "non-desired" users to access data, is to add one or more Custom Claims to the desired accounts and use these claims in the Security Rules: See the doc for more details.

Renaud Tarnec
  • 79,263
  • 10
  • 95
  • 121
  • Thanks Renaud for taking time to help me! The API key is indeed available in my main.dart.js. The hacker claims he found "our database credentials" in "a response to a request". Any ideas how this would be done? If I understand you correctly, adding anonymous sign in will not increase security I guess since everybody will be able to sign in anonymously anyhow, right? – Marc Van Daele May 24 '23 at 13:29
  • 1
    Hi Marc, actually O don't know the details on how to get the API key in a Flutter app. For a web app you can just find it in the JS files in the case of a SPA. And yes adding anonymous sign in will not increase security as explained by my friend Alex in the comments of his answer. – Renaud Tarnec May 25 '23 at 09:28
2

The security rules are allow read, write;

If you're using these settings it means that you allow anybody who knows your project ID to read/write to/from your database. Which is obviously bad, since malicious users can take advantage of it. It’s true that you can use these settings for a small amount of time for testing purposes, but never in a production environment.

The most important part when it comes to security rules is Firebase Authentication, meaning that you can allow access only to the users that are authenticated to perform operations in your database.

In an attempt to improve this, I have added anonymous authentication to my project and modified the security rules to allow read, write: if request.auth != null;

These rules are better than the previous ones. However, it will allow anybody who knows your project ID and is authenticated to read/write to/from your database. If you want a more granular set of security rules, then you can use:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{uid} {
      allow create: if request.auth != null;
      allow read, update, delete: if request.auth != null && request.auth.uid == uid;
    }
  }
}

This will allow only the authenticated users to create a document, but to read, update and delete only the ones who have the UID from the authentication the same as the one in the database.

Besides security rules, I also recommend you use Firebase App Check, which is an additional layer of security that can help you protect access to your Firebase services by attesting that incoming requests are coming from your app. On the other is blocking the traffic that doesn't have valid credentials.

So it's a mix of solutions.

Alex Mamo
  • 130,605
  • 17
  • 163
  • 193
  • Thanks Alex for helping me! If I understand you correctly, adding anonymous authentication does not improve security by itself but it allows to create better security rules, right? In my case, I have a document that contains the top-100 leaderboard (as an array). Whenever the user has a good enough time, we update this leaderboard from the web-application. I guess this is not a good approach, security wise? Eg is it possible to create rules to only allow "append" to an array but not a delete? – Marc Van Daele May 24 '23 at 14:28
  • A better approach would probably be to store the users data in /users/{uid} and have a cloud function listen to updates and let the cloud function update the leaderboard. – Marc Van Daele May 24 '23 at 14:29
  • (although even then, a malicious user can still force incorrect data to /users/{uid} and manipulate the leaderboard I guess) – Marc Van Daele May 24 '23 at 14:42
  • Yes, that's correct. Implementing anonymous authentication doesn't improve security by itself but it allows you to create better security rules. And yes, it's perfectly possible to limit an array to only get updates but not deletes. Definitely yes, it will always be better to use Cloud Functions for such update operations rather than performing the updates in client-side code. Note, that running Cloud Functions from the server, which is considered a trusted environment bypasses the security rules entirely. So there is nothing to force here. – Alex Mamo May 24 '23 at 18:00
  • Did my answer help? Can I help you with other information? – Alex Mamo May 25 '23 at 05:32
  • 1
    Thanks for pointing me towards App Check. That seems to be an easy, short term, additional layer of security. In the (somewhat) longer term, I'll definitely have to revise my database structure and corresponding security rules. – Marc Van Daele May 25 '23 at 07:11