2

Recently I've received bunch of Firebase notifications regarding:

[Firebase] Your Cloud Firestore database has insecure rules

We've detected the following issue(s) with your security rules:any user can write to your entire database. Because your project does not have strong security rules, anyone can access your entire database. Attackers can steal, modify, or delete your data, and they can drive up your bill.`

Edit2: What I need, is to allow write for everyone without any need to sign in, but only the admin account should be able to read it from Firebase console.

Realtime Database rules:

{
  "rules": {
    ".read": "auth != null",
    ".write": "auth != null"
  }
}

Cloud Firestore rules:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow write;
    }
  }
}

Edit: One of the Databases structure in JSON, others looks similar:

{
  "battles" : {
    "-KjiAFLI8oE_12345678" : {
      "full" : true,
      "player1" : {
        "movement" : {
          "down" : false,
          "left" : false,
          "right" : false,
          "up" : false
        },
        "position" : {
          "x" : 0,
          "y" : 0
        }
      },
      "player2" : {
        "movement" : {
          "down" : false,
          "left" : false,
          "right" : false,
          "up" : false
        },
        "position" : {
          "x" : 0,
          "y" : 0
        }
      }
    },
    "-KjiAMVvJydR12345678" : {
      "full" : true,
      "player1" : {
        "movement" : {
          "down" : false,
          "left" : false,
          "right" : false,
          "up" : false
        },
        "position" : {
          "x" : 0,
          "y" : 0
        }
      },
      "player2" : {
        "movement" : {
          "down" : false,
          "left" : false,
          "right" : false,
          "up" : false
        },
        "position" : {
          "x" : 0,
          "y" : 0
        }
      }
    }
  }
}

Edit3: In contrast to the Firebaser's answer to Firebase email saying my realtime database has insecure rules I don't want to/use Firebase Authentication/SSO.

Given these scenario do I have to/shall I modify them somehow?

Daniel Danielecki
  • 8,508
  • 6
  • 68
  • 94
  • 1
    I think it's a bit beyond the scope of Stack Overflow for us to translate your list of use-cases to working code/rules. The email should contain a link to this documentation about how to get started with security rules: https://firebase.google.com/docs/rules/get-started If you get stuck on a specific rule, I recommend posting details about that specific rule. – Frank van Puffelen Jan 05 '21 at 15:43
  • Disagree. All use cases are related to writing to a database without the need to have any privileges. There are many projects with such a case, and people are confused. PS. Please don't remove my code snippets, I also wanted to showcase security rules to my `Realtime Database`. In both cases the logic is the same. – Daniel Danielecki Jan 05 '21 at 15:51
  • will you please share your firestore database structure? – MehranB Jan 05 '21 at 16:14
  • @MehranB of course, edited. – Daniel Danielecki Jan 05 '21 at 16:17
  • It’s a good idea to include code and structures as *text*, not links and images. That way, if they are needed in an answer, they can be copied and pasted. To get your Firebase structure, use the Firebase console->Export JSON and copy and paste a snippet of your structure. See [images and links are evil](http://idownvotedbecau.se/imageofcode). – Jay Jan 05 '21 at 21:35
  • I am not sure what you're asking here and an accurate answer is impossible without understanding the scope of the use cases. For example, one scenario you mentioned *Storing users gameplay data*; with the rules you're showing, any authenticated user can read and write to the gameplay data. Is that important? Under what circumstances should an auth'd user be able to access that? Should it be all users? Some users? Just that user? Another example *Storing data about uploaded files which are being send out to an email* - are emails stored in the database? Who should be able to access them? – Jay Jan 05 '21 at 21:46
  • There's also a great question and answer already posted. Take a look at [Firebase email saying my realtime database has insecure rules](https://stackoverflow.com/questions/51392059/firebase-email-saying-my-realtime-database-has-insecure-rules) – Jay Jan 05 '21 at 22:32
  • @Jay thanks for the link, I haven't seen it. Unfortunately, my question isn't about SSO's. I've made my question less vague. – Daniel Danielecki Jan 06 '21 at 09:51
  • @Jay - wasn't aware about the DB structure how it's being exported in `Firebase`. I've added the `JSON`, I almost always add code :) – Daniel Danielecki Jan 06 '21 at 10:11
  • The SSO part was kind of a side point, however, without understanding your auth intention, discussing the rules will be moot because it relies on some kind of authentication. When you say *I don't want to/use Firebase Authentication/SSO* does that mean you want to use Firebase [Using a Custom Authentication System](https://firebase.google.com/docs/auth/ios/custom-auth) or does it mean something else? Also, this *is to allow write for everyone without any need to sign in* would mean that anyone at any time could change any values or completely erase your database. Is that the desired behavior? – Jay Jan 06 '21 at 17:40
  • I'm not gonna to use Firebase/GCP anytime anymore. Moving to AWS from now on. What you guys (Firebasers) have done basically downvoted question which has been asked due to the lack of documentation and even less docs about `Security Rules`. If player A starts a battle with a player B, I want the metadata about the battle. Then once the battle starts what's the point for them to be authenticated? Case 2: What's the point to require authentication if I want to upload a file? Yes, I want to have an access to console.firebase.google.com as Admin to see everything, but no one should be able to read – Daniel Danielecki Jan 06 '21 at 19:35
  • Too long for previous comment: *if a user browsing my website wants to upload a file, which is attached to an email as attachment*. Can't imagine anyone using authentication to do so... – Daniel Danielecki Jan 06 '21 at 19:38
  • I believe it was closed because it's open ended to be answered specifically; there are many use cases to consider. There is an answer but again, it's generic because there are so many variables. Case 1: If two players start a battle and one isn't authenticated and can freely write data to a node in Firebase, they could win the battle every time. Case 2: *What's the point to require auth to upload a file?* So you know who uploaded the file, right? Part of that process is writing the file to Storage and keeping a ref to it in Firebase. Again, if anyone can write, anyone can delete your database. – Jay Jan 06 '21 at 22:15
  • And one additional thought - if your app never allows users to see any data, but only write data, what's that use case look like? How do you track what data goes with which user with no authentication? Or maybe that's not important? I think if you can explain that in clear terms then we can provide you a dynamite answer and maybe the rules to go with it. That's why we ask for a specific use case so we can make the rules fit it. Hope that helps. – Jay Jan 06 '21 at 22:19

2 Answers2

2

I get these emails, but there's nothing that can be done to fix mine, because that's just the way my system works.

In your case, the reason is:

allow write;

in your Cloud Firestore rules. This means anyone can access the database from anywhere.

Thus,

Attackers can steal, modify, or delete your data, and they can drive up your bill.

Change this rule to only allow authenticated access, and the alert should stop.

JaffaKetchup
  • 1,151
  • 10
  • 26
  • Thanks for the contribution, but I really need the `write` rule :) Was wondering if there's any way to get rid off this alert, or simply improve my `Security Rules`, but keeping my current ones. The open `write` is also my desired functionality of writing for the given scenarios. – Daniel Danielecki Jan 05 '21 at 15:06
  • @DanielDanielecki In that case, I don't think there's a way to prevent the emails. Maybe setup a filter or rule in your email client and just delete emails with that subject and sender. – JaffaKetchup Jan 05 '21 at 16:20
2

I can think of two solutions without risking compromising security (to some extent):

  1. You can use Authentication for users and only allow read or write access to authenticated users. (Which I understand is a hassle specially when coding a game.) like so:
match /databases/{database}/documents {
    match /{document=**} {
      allow write: if request.auth != null;
    }
  }
}
  1. You can use some sort of 10-char sequence for example combined with the document names in your database (for example, "Users-xQnFiECweq") and then edit your security rules accordingly.

for example:

match /Users-xQnFiECweq {
    match /Courses-QrmGvMgF9C {
        match /{multiSegment=**}{
            allow write;
        }   
    }
}

the string values at the end of document or collection names kind of act as passwords that only you know and it makes it difficult for another person to guess the exact structure to your database.

I understand it's a bit of a strange approach but it's better than giving write access to just everyone.

MehranB
  • 1,460
  • 2
  • 7
  • 17
  • In most projects I've been using the second approach, but not on `Security Rules` level. Simply from an application level. Do you think it does make any sense? – Daniel Danielecki Jan 05 '21 at 20:33
  • Not really. the security rules are preventing and granting access. the app just sends a request. it's the server's job to validate it. I'm not sure I understand what you mean by _"doing it from application level"_. can you elaborate please? – MehranB Jan 05 '21 at 20:36
  • I meant I've had defined the `Courses-QrmGvMgF9C` on the application level. For example "on write to `Courses-QrmGvMgF9C` upload a file". – Daniel Danielecki Jan 05 '21 at 20:37
  • but if the security rules are not checking to see if the name of the requested document and the available document match, what difference does it make? any request to any of the documents is allowed to write. – MehranB Jan 05 '21 at 20:40
  • While this is an accepted answer, it doesn't really work in the big picture without further refinement. *Every authenticated user* can read *everything in the database* which makes the following statement not applicable: *difficult for another person to guess the exact structure to your database* as they can see the structure. Additionally, they can add, change and delete data as well. Point being that if your data is important, rules should be implemented that protect that specific data for specific use cases; The only user that can write to User_A's node is User_A, for example. – Jay Jan 05 '21 at 22:02
  • @Jay I understand you point, Jay. In my answer i focused on the rules and the hierarchy. OP wanted to know how he could get rid of the email and i suggested to change the rules this way and the emails will stop. this was not a security advice. I have also mentioned that this helps _to some extent_. If you can give a better idea. I would personally love to hear it since I dealt with this problem at some point myself. – MehranB Jan 05 '21 at 22:08
  • @Jay Plus if authenticated users can read the database, it is my understanding that they have sent a request through the app cuz otherwise the request won't be authenticated. will it? – MehranB Jan 05 '21 at 22:15
  • Not beating you up as it's a generic good answer. The problem with the question is that it's *super vague* and there's no way to present any kind of real solution without understanding what data needs to be secured and in what fashion. On your other comment; anyone can authenticate to Firebase at any time - remember, it's web accessible; those rules don't provide any real security at all. So if I auth, I can then add points to my game score, grab everyones emails to spam them or... delete your database! That's why implementing proper Rules are incredibly important. – Jay Jan 05 '21 at 22:24
  • Also, see the link I added in a comment to the question - really good question and post by a Firebaser. – Jay Jan 05 '21 at 22:33
  • @Jay I appreciate the explanation. Will check out the link. Thanks a lot – MehranB Jan 06 '21 at 05:08
  • I've edited the question. The goal is to **allow write for everyone, but only the admin account should be able to read it from Firebase console**. – Daniel Danielecki Jan 06 '21 at 09:58