If you only set data from your own development machine, consider using the Admin SDK. This SDK accesses the backend with administrative permissions, so it bypasses security rules. This means you can have these rules:
{
"rules": {
".read": true,
".write": false
}
}
The typical first step I do when I create an application admin page (usually a simple StackBlitz or JSBin), even before signing in the users anonymously, is to sign myself in anonymously, log my UID, and then only give write permissions to my UID.
In rules that'd look something like:
{
"rules": {
".read": true,
".write": "auth.uid === 'myUid'"
}
}
Later if I expand the user sign-in (even if again only for fellow administrators), I expand this to a more elaborate check, such as:
{
"rules": {
".read": true,
".write": "auth.uid === 'myUid' ||
(auth.token.email_verified == true &&
auth.token.email.matches(/.*@google.com$/))"
}
}
With all of the above rules, you'll still get a warning about the user's ability to read your entire database though. The main problem with the top-level ".read": true
is that it allows crawling your website with a single HTTP GET to https://yourproject.firebaseio.com/.json
. There are quite some scripts out there that use this to find user information
If this is not a concern for your app, you can disable the alerts at this point.
If it is a concern, you can consider protecting the data by encoding the access patterns in your rules.
For example, if you have one top-level node that contains a list of all games, and then another top-level node that then contains the move for each game, you might push the read-permissions down to those levels:
{
"rules": {
"games": {
".read": true,
},
"moves": {
"$gameid": {
".read": true
}
}
}
}
This this structure, anyone can read the full list of games. But one can only read the moves for a single game at the time. This matches with an application where you first see a list of games, and then see the move for a game that you select.
With these rules the user still has access to all data, but only if they follow the rules of your application. And (maybe more importantly) the blatant top-level https://yourproject.firebaseio.com/.json
access won't work anymore.