Michel
Michel

Reputation: 11753

Firebase Realtime database - insecure rules

I received a message in Firebase letting me know that my project Realtime database has insecure rules. But when I check it, I don't quite see what is insecure.

It shows up like this:

{
  "rules": {
    ".read": true,
    ".write":  "(auth != null) && (auth.uid ==   '123...myUID ...xyz')",
    "CollectionOne": {
      ".indexOn": ["name", "url"]
    },
    "CollectionTwo": {
      ".indexOn": ["name"]
    }
  }
}

I left the read access the way it is, because this is supporting a web site. So anyone visiting the site should be able to read the data.

And for the write access, as far as I can see, I am the only one who can write.

Just one note, I have a third collection (CollectionThree) which is not mentioned in the rules. Could that be the reason?

Beside I could also imagine that the read access could be given to only the web server in order to serve the contents to the visitors and not directly to anyone, but I don't think that is the case. And if this was the case I wouldn't know how to set this rule.

If someone can shed some light on this, that would be helpful.

Upvotes: 1

Views: 343

Answers (2)

Frank van Puffelen
Frank van Puffelen

Reputation: 598623

anyone visiting the site should be able to read the data.

While that is a valid requirement, right now even people who are not visiting your web site can read the entire database with a single call. In fact, it's as simple as opening the URL https://<yourproject>.firebaseio.com/.json (or a similar URL for your region) to scrape all data from our database.

Typically your code will access the data in a more granular level. In fact, looking at your rules, I expect that your code runs queries or accesses individual child nodes of CollectionOne and CollectionTwo. If that is what your application code does, it is also all that you security rules should allow.

So one step better would be:

{
  "rules": {
    ".write":  "(auth != null) && (auth.uid ==   '123...myUID ...xyz')",
    "CollectionOne": {
      ".read": true,
      ".indexOn": ["name", "url"]
    },
    "CollectionTwo": {
      ".read": true,
      ".indexOn": ["name"]
    }
  }
}

Now the URL patterns I showed above won't work anymore, and a malicious user must know the name of your top-level nodes in order to access the data in them.

For more on this, also see:

Upvotes: 3

Berci
Berci

Reputation: 3386

The firebase docs suggest to use more specific rules. (so give each collection the rules you've given to your entire db should definitely help)

One reason for this is the following:

Rules are applied as OR statements, not AND statements. Consequently, if multiple rules match a path, and any of the matched conditions grants access, Rules grant access to the data at that path. Therefore, if a broad rule grants access to data, you can't restrict with a more specific rule. You can, however, avoid this problem by making sure your Rules don't overlap too much. Firebase Security Rules flag overlaps in your matched paths as compiler warnings.

You can find this and more about this topic here

Upvotes: 2

Related Questions