Currently, I have implemented a project folder structure similar to the below
I have added the Phone authentication in my code.
Project folder structure
Now with the help of Firebase rules, I restricted my users to access only authenticated phone number folder
Here is the Firebase rules Implemented
With the above rules, admin able to read and write the data.
But, now problem coming for Suppliers, since they have logged in their phone number and it is different than Admin number, hence they are not able to access the Admin phone number folder.
Could you suggest me to improve the rules here?
To start with, it is not necessary to have the user_id at two levels, one is enough.
I think what you need is the following
{
"rules": {
"$admin_ID": {
".read": "$admin_ID === auth.uid"
".write": "$admin_ID === auth.uid"
"$supplier_id": {
".read": "$supplier_id === auth.uid"
".write": "$supplier_id === auth.uid"
}
}
}
}
Related
Good afternoon, I wonder if it is possible in firebase to allow reading and writing a file from a given URL?
Example:
{
"rules": {
".read": true, // www.myweb.com.br
".write": true // www.myweb.com.br
}
}
No you cannot, it is actually pointless to do that, as a malicious user will replicate the whole request and edit the source origin to www.myweb.com.br.
To achieve the desired behavior that nobody outside of www.myweb.com.br can access your database. you simply have to set only www.myweb.com.br as an authorized authentication domain, this way even if somebody took your firebase project data (which is public information) and used them on their website, users will not be able to login.
you can view authorized authentication domain in https://console.firebase.google.com/project/[yourProjectID]/authentication/providers
then to answer your question you set
{
"rules": {
".read": "auth != null",
".write": "auth != null"
}
}
this will allow only authenticated users on an authorized domain to use the database
I have the following Firebase realtime database rules:
{
"rules": {
".read" : "auth != null",
".write": false,
"Games": {
".indexOn" : "WeekId"
},
"Version": {
".read" : true
}
...
}
I keep getting the following email from Google:
[Firebase] Your Realtime Database 'xxx-9e542' has insecure rules`
We've detected the following issue(s) with your security rules:
any logged-in user can read your entire database
Without strong security rules, anyone who has the address of your database can read / write to it, leaving your data vulnerable to attackers stealing, modifying, or deleting data as well as creating costly operations.
So based on my rules above, I KNOW, that I have rules in place to allow logged in users to read the Games node and that ALL users can read the Version node even non authenticated users.
As far as I know, it needs to be this way because I require ALL logged in users to be able to access the Games node information, else how would they be able to view the list of games they can select from!?
As for the Version node, I use that in the instance I need everyone that downloaded my app to "Force Upgrade" my app cause of a change that is required. In this instance, I would need the user that have downloaded an older version of my app and that are either "logged in" or "not logged in" and force them to update the app or else they can not use it.
Can anyone let me know if I am off base with how I structured my security rules or is this "normal" and that I am receiving the email just as a FYI!?
How have others setup their rules!? or what are the "best practices" for setting up security rules!? esp. if you need logged in users to access the information of any particular node(s) 24/7!?
The main problem with your current rules is that anyone can sign in through the API and read your entire database, even if they know nothing about your application. They can just read the root of the database, and then start looking at your data.
The first step to improve security would be to not allow read on the top-level, but only at lower levels:
{
"rules": {
".write": false,
"Games": {
".read" : "auth != null",
".indexOn" : "WeekId"
},
"Version": {
".read" : true
}
...
}
Now nobody can read from the root, and you must know that Games or Version node exists in order to read it.
I am using Relatime database from firebase to read few flags and do some actions in android app. I used to get mail of insecure database read and write rules so I changed to following:
{
"rules": {
".read": "true",
".write": "false"
}
}
And now, I only get mail about insecure read.
[Firebase] Your Realtime Database 'abc-xyz' has insecure rules
We've detected the following issue(s) with your security rules:
any user can read your entire database
But if I change read to false then I am unable to read any value changes in real time. Can someone please help me understand how do I secure both read and write but also able to keep reading values from app?
PS: I don't use Firebase auth in my app as of now.
Firebase Auth is a cool thing, if you don't want your user to log into the authorization provider account, you can use an anonymous account which gives you a unique user ID of your app, etc.
Then you can write rules like:
"rules": {
".read": "auth != null",
".write": "auth != null"
}
If you don't store user data, you probably don't need any authorization. You can still restrict reading and writing of users by adding some area when read / write is available.
E.g:
"rules": {
"PublicData":{
"SomePublicChild":{
"ChildProperty1": { ".validate":true },
"ChildProperty2": { ".validate":true },
"$other": {".validate":false },
},
".write":true,
".read":true,
".validate":"newData.hasChild(SomePublicChild)"
},
"PrivateData":{
".write":false,
".read":false,
}}
These rules will allow anyone to write / read to the PublicData node and to anyone else to write / read the PrivateData node. The rules will also protect the structure of your public data, they only allow writing to the PublicData object with the ChildProperty1 or ChildProperty2 properties, and will block writes with any other property key.
It's not big thing but you won't recive more mail about insecure rules.
I have a Firebase Realtime Database set up with a bunch of basic rules revolving around basic user authentication:
{
"rules": {
".read": false,
".write": false,
"users": {
"$user_id" : {
".read": "$user_id === auth.uid",
".write": "$user_id === auth.uid",
}
}
}
}
These rules depend on the auth.uid built-in Firebase variable, which is accessible during development/production as a user is logged in with any given provider.
However, when I am running jest tests on a duplicated database with the same rules, I do not have access to this auth.uid since there is no actual user logged in.
Is there a way to solve this? A way to perhaps mock some sort of testing user on Firebase itself or through my client-side test code?
I would like the testing to run on a database that is as similar as possible to the regular database. I don't want to have a different rules structure on the test database.
Possible solution I came up with which is more of a workaround is this:
Set up a test environment variable like FIREBASE_TEST_UID.
Reference this uid when running tests.
Manually change the rules comparing the $user_id" to auth.uid to the compare it with the actual stored FIREBASE_TEST_UID
Now the database is protected from reading and writing by public non "authenticated" users while the rules structure is left similar and the FIREBASE_TEST_UID is private (.gitignored env file).
I am trying to learn using Firebase rules, but having some trouble. I have two nodes in my database a meetups and comments. Both have a meetupID property. I am trying to write a rule so that any writes to the comments node only happen if a child under meetups exists matching the meetupIDof a comment. Saving a new value to comments works fine, but deleting gives me a permission denied. Here is what I have:
"comments": {
".read": "auth != null",
"$meetupID": {
".write": "auth != null && root.child('meetups').hasChild($meetupID)"
},
I suspect this is because when I delete a meetup from the app I also delete the comments for that meetup at the same time which causes this rule to deny permission. Is there some way I can re-write this rule to make it work successfully for both saving and deleting values?
I appreciate your help. Thank you.