Firestore security rules

[pietrop]

from bbc#276

---

Describe the bug

I think on your end the data is is also organized as follows(?):

• projects collection where the project document contains the transcripts collection.
• the project document also contains a roles attributes as a hash map where the key is the user email and the value is the role type : owner, write, read.

At the moment client side we query the /projects collection and only display to the users the once they are associated with.

by using list for projects In the current security rules and locking down further other operations and nested routes.

In some situations, it's useful to break down read and write into more granular operations. For example, your app may want to enforce different conditions on document creation than on document deletion. Or you may want to allow single document reads but deny large queries.

A read rule can be broken into get and list, while a write rule can be broken into create, update, and delete

From firestore docs Granular operations

This is because a collection, especially at the top level, cannot have tighter security without disallowing the list operation.

All match statements should point to documents, not collections.

From firestore Basic read/write rules

The problem is that when we list a project, "anyone" can theoretically see the project title, description but most importantly the emails of the users associated with that project and their corresponding roles.

Expected behavior

Ideally we'd want to be able to lock down the project list or restructure the data to be more secure.

Additional context

looking at the firestore doc Securely query data & Secure data access for users and groups there's another pattern, we can consider where the /projects/ collection could be locked down, and a /users/{userId} collection/document could contain the info to match users to projects.