Reputation: 11753
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
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
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