Restricting child/field access with security rules

Question

I\'m writing an app that allows users to submit nominations which are moderated before being displayed to other users. This requires a number of restrictions I\'ve so far be

Answer 1

If I fully grok the way security rules work (I'm just learning them myself), then when any one rule allows access, access is granted. Thus, they are read as follows:

• nominations ".read": true, ACCESS GRANTED
• other rules: not read

Furthermore, if that rule is removed, $nominationId ".read" grants access if the record is approved; therefore, the .read in phone and state become superfluous whenever it's approved.

It would probably be simplest to break this down into public/ and private/ children, like so:

nominations/unapproved/          # only visible to logged in users
nominations/approved/            # visible to anyone (move record here after approval)
nominations/approved/public/     # things everyone can see
nominations/approved/restricted/ # things like phone number, which are restricted

UPDATE

Thinking this over even more, I think you'll still encounter an issue with making approved/ public, which will allow you to list the records, and having approved/restricted/ private. The restricted data might need its own path as well in this use case.

Answer 2

Kato's right. It's important to understand that security rules never filter data. For any location, you'll either be able to read all of the data (including its children) or none of it. So in the case of your rules, having a ".read": true under "nominations" negates all of your other rules.

So the approach I'd recommend here is to have 3 lists. One containing nomination data, one to contain the list of approved nominations, and one to contain the list of pending nominations.

Your rules could be like so:

{
  "rules": {
    // The actual nominations.  Each will be stored with a unique ID.
    "nominations": {
      "$id": {
        ".write": "!data.exists()", // anybody can create new nominations, but not overwrite existing ones.
        "public_data": {
          ".read": true // everybody can read the public data.
        },
        "phone": {
          ".read": "auth != null", // only authenticated users can read the phone number.
        }
      }
    },
    "approved_list": {
      ".read": true, // everybody can read the approved nominations list.
      "$id": {
        // Authenticated users can add the id of a nomination to the approved list 
        // by creating a child with the nomination id as the name and true as the value.
        ".write": "auth != null && root.child('nominations').child($id).exists() && newData.val() == true"
      }
    },
    "pending_list": {
      ".read": "auth != null", // Only authenticated users can read the pending list.
      "$id": {
        // Any user can add a nomination to the pending list, to be moderated by
        // an authenticated user (who can then delete it from this list).
        ".write": "root.child('nominations').child($id).exists() && (newData.val() == true || auth != null)"
      }
    }
  }
}

An unauthenticated user could add a new nomination with:

var id = ref.child('nominations').push({ public_data: "whatever", phone: "555-1234" });
ref.child('pending_list').child(id).set(true);

An authenticated user could approve a message with:

ref.child('pending_list').child(id).remove();
ref.child('approved_list').child(id).set(true);

And to render the approved and pending lists you'd use code something like:

ref.child('approved_list').on('child_added', function(childSnapshot) {
  var nominationId = childSnapshot.name();
  ref.child('nominations').child(nominationId).child('public_data').on('value', function(nominationDataSnap) {
    console.log(nominationDataSnap.val());
  });
});

In this way, you use approved_list and pending_list as lightweight lists that can be enumerated (by unauthenticated and authenticated users respectively) and store all of the actual nomination data in the nominations list (which nobody can enumerate directly).

Answer 3

this thread is a little outdated and it may have a solution via rules, but as the video says, its a neat trick: https://youtu.be/5hYMDfDoHpI?t=8m50s

This may be not a good practice since the firebase docs say that rules are not filters: https://firebase.google.com/docs/database/security/securing-data

I'm no specialist in security but I tested the trick and it worked fine for me. :)

So I hope a better understanding of the security issues around this implementation.