Firestore Security Rules - How can I check that a field is/isn't being modified?

Question

For the life of me, I cannot understand why the following is resulting in a false for allowing writes. Assume my users collection is empty to start, and I am writing a document of the following form from my Angular frontend:

{
  displayName: 'FooBar',
  email: 'foo.bar@example.com'
}

My current security rules:

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      function isAdmin() {
        return resource.data.role == 'ADMIN';
      }

      function isEditingRole() {
        return request.resource.data.role != null;
      }

      function isEditingOwnRole() {
        return isOwnDocument() && isEditingRole();
      }

      function isOwnDocument() {
        return request.auth.uid == userId;
      }

      allow read: if isOwnDocument() || isAdmin();
      allow write: if !isEditingOwnRole() && (isOwnDocument() || isAdmin());
    }
  }
}

In general, I want no users to be able to edit their own role. Regular users can edit their own document otherwise, and admins can edit anyone's.

Stubbing isEditingRole() for false gives the expected result, so I've narrowed it down to that expression.

The write keeps coming back false, and I cannot determine why. Any ideas or fixes would be helpful!

Edit 1

Things I've tried:

function isEditingRole() {
  return request.resource.data.keys().hasAny(['role']);
}

and

function isEditingRole() {
  return 'role' in request.resource.data;
}

and

function isEditingRole() {
  return 'role' in request.resource.data.keys();
}

Edit 2

Note that eventually, admins will set a role for users, so a role could eventually exist on a document. This means that, according to the Firestore docs below, the request will have a role key, even if wasn't in the original request.

Fields not provided in the request which exist in the resource are added to request.resource.data. Rules can test whether a field is modified by comparing request.resource.data.foo to resource.data.foo knowing that every field in the resource will also be present in request.resource even if it was not submitted in the write request.

According to that, I think the three options from "Edit 1" are ruled out. I did try the suggestion of request.resource.data.role != resource.data.role and that's not working either... I'm at a loss and am beginning to wonder if there's actually a bug in Firestore.

Answer 1

Your rules will be a lot more readable and maintainable if you create a custom function to check for updates. For example:

service cloud.firestore {
  match /databases/{database}/documents {
    function isUpdatingField(fieldName) {
      return (!(fieldName in resource.data) && fieldName in request.resource.data) || resource.data[fieldName] != request.resource.data[fieldName];
    }

    match /users/{userId} {
      // Read rules here ...
      allow write: if !isUpdatingField("role") && !isUpdatingField("adminOnlyAttribute");
    }
  }
}

Answer 2

So in the end, it seems I was assuming that resource.data.nonExistentField == null would return false, when it actually returns an Error (according to this and my tests). So my original solution may have been running into that. This is puzzling because the opposite should work according to the docs, but maybe the docs are referring to a value being "non-existent", rather than the key -- a subtle distinction.

I still don't have 100% clarity, but this is what I ended up with that worked:

function isAddingRole() {
  return !('role' in resource.data) && 'role' in request.resource.data;
}

function isChangingRole() {
  return 'role' in resource.data && 'role' in request.resource.data && resource.data.role != request.resource.data.role;
}

function isEditingRole() {
  return isAddingRole() || isChangingRole();
}

Another thing that still puzzles me is that, according to the docs, I shouldn't need the && 'role' in request.resource.data part in isChangingRole(), because it should be inserted automatically by Firestore. Though this didn't seem to be the case, as removing it causes my write to fail for permissions issues.

It could likely be clarified/improved by breaking the write out into the create, update, and delete parts, instead of just allow write: if !isEditingOwnRole() && (isOwnDocument() || isAdmin());.

Answer 3

I solved it by using writeFields. Please try this rule.

allow write: if !('role' in request.writeFields);

In my case, I use list to restrict updating fields. It works, too.

allow update: if !(['leader', '_created'] in request.writeFields);

Answer 4

The solution of Tom Bailey (https://stackoverflow.com/a/48177722/5727205) did look promising.

But in my case I needed to prevent a field from being edited, and could have the case, that the field simply does not exist on the existing data. Thereby I added a check if the field exists.

This solution does check two checks:

1. If the field is not in request and non in the existing data (equals field not modified)
2. or request and existing data are the same (equals field not modified)

 function isNotUpdatingField(fieldName) {
   return
     ( !(fieldName in request.resource.data) && !(fieldName in resource.data) ) || 
     request.resource.data[fieldName] == resource.data[fieldName];
}

Answer 5

With this single function you can check if a fields are/aren't being created/modified.

function incomingDataHasFields(fields) {
    return ((
        request.writeFields == null
        && request.resource.data.keys().hasAll(fields)
    ) || (
        request.writeFields != null
        && request.writeFields.hasAll(fields)
  ));
}

Usage:

match /xxx/{xxx} {    
    allow create:
        if incomingDataHasFields(['foo'])              // allow creating a document that contains 'foo' field
           && !incomingDataHasFields(['bar', 'baz']);  // but don't allow 'bar' and 'baz' fields to be created

Answer 6

Here's a function that takes all of this into account:

• Doesn't trigger security rule errors like "Property name is undefined on object".
• Works with set() and update()
• Works when explicitly trying to delete the field using firebase.firestore.FieldValue.delete()
• Can be used both when creating and updating a document (update, create).

function fieldNotWrittenByUser(field) {
  return (
    (
      (field in request.resource.data)
      && (resource != null && field in resource.data)
      && request.resource.data[field] == resource.data[field]
    )
    || (
      !(field in request.resource.data) && (resource == null || !(field in resource.data))
    )
  )
}

Explanation

Remember that request.resource.data represents the resource after a successful write operation, i.e. the "future" document.

If the field is present on the future document, it must be identical to its value on the existing document.

Alternatively, if the field isn't present on the future document, the operation is only allowed if the resource doesn't yet exist, or if the existing document also lacks the field.

Source: https://www.sentinelstand.com/article/firestore-security-rules-examples

Answer 7

Since reference to writeFields in documentation has disappeared, I had to come up new way to do what we could do with writeFields.

function isSameProperty(request, resource, key) {
    return request.resource.data[key] == resource.data[key]
}

match /myCollection/{id} {
    // before version !request.writeFields.hasAny(['property1','property2','property3', 'property4']);
  allow update: isSameProperty(request, resource, 'property1')
    && isSameProperty(request, resource, 'property2')
    && isSameProperty(request, resource, 'property3')
    && isSameProperty(request, resource, 'property4')
  }

Answer 8

This might seem like over kill but for updating documents where you might have other fields that are not user generated, eg. roles, created etc. you need functions that can test that those fields don't change. Hence meet these three FNs.

function hasOnlyFields(fields) {
  if request.resource.data.keys().hasOnly(fields) 
}
function hasNotChanged(fields) {
  return (fields.size() < 1 || equals(fields[0]))
    && (fields.size() < 2 || equals(fields[1]))
    && (fields.size() < 3 || equals(fields[2]))
    && (fields.size() < 4 || equals(fields[3]))
    && (fields.size() < 5 || equals(fields[4]))
    && (fields.size() < 6 || equals(fields[5]))
    && (fields.size() < 7 || equals(fields[6]))
    && (fields.size() < 8 || equals(fields[7]))
    && (fields.size() < 9 || equals(fields[8]))
}
function equals(field) {
  return field in request.resource.data && field in resource.data && request.resource.data[field] == request.resource.data[field]
}

So on update of say user document, where the user may only update their name, age, and address, but not roles and email you can do:

allow update: if hasOnlyFields(['name', 'age', 'address']) && hasNotChanged(['email', 'roles'])

Note the hasNotChanged can check up to 9 fields. Also these aren't the only checks you would want to do. You'd need to check the the types and ownership of the document as well.

Answer 9

Found this rule to work quite well:

function propChanged(key) {
  // Prop changed if key in req but not res, or if key req and res have same value
  return (
    (key in request.resource.data) && !(key in resource.data)
  ) || (
    (key in request.resource.data) && request.resource.data[key] != resource.data[key]
  );
}

Answer 10

I wrote these functions based on official documentation (as of 2022):

Verifying that specified fields are not changed

Firebase documentation

By using the hasAny() method on the set generated by affectedKeys() and then negating the result, you can reject any client request that attempts to change fields that you don't want changed.

function verifyUnchangedFields(fields) {
    return !request.resource.data.diff(resource.data).affectedKeys().hasAny(fields)
}

Explicitly listing allowed and required fields

Firebase documentation

You can combine hasAll and hasOnly operations together in your security rules to require some fields and allow others. For instance, this example requires that all new documents contain the name, location, and city fields, and optionally allows the address, hours, and cuisine fields.

function verifyFields(required, optional) {
  let allAllowedFields = required.concat(optional);
  return request.resource.data.keys().hasAll(required) &&
    request.resource.data.keys().hasOnly(allAllowedFields);
}

Usage example

Use those functions as part of your rules, eg:

      allow update: if isOwner() && isCorrectModeratedFlag()
      && verifyFields(['id', 'isModerated', 'nickname', 'updatedAt', 'status'], ['photoURL'])
      && verifyUnchangedFields(['id']);

Answer 11

Here's my function that covers all states:

function isUpdating(fieldName) {
      return fieldName in request.resource.data
        && (!(fieldName in resource.data) || resource.data[fieldName] != request.resource.data[fieldName]);
    }

This checks whether fieldName will be present in the document after the update. If true, it will check whether fieldName is being added or if its value will change.