Filtering and Permissions in Firebase

Question

I asked this question about my Firebase implementation. Essentially, I was trying to structure my Firebase database so that I could have a collection of objects, with some users accessing a subset of these objects.

In my example, I have tasks. Multiple users will use this database, and per Firebase's suggestion, all the tasks for all users are flattened as children of one parent node. Each user can access their own tasks, indicated by a creatorId in a task object. Perhaps in the future permissions could be extended so tasks could be shared with other users. But for now, just ownership and the creator can read and write their own tasks.

This is trivial to implement using queries. I'm no security expert, but it seems to me that somehow enforcing these rules separate from queries inside client implementation is an important security consideration. Even if my client limits access in this way, and all access requires authentication with our custom token provider, it seems possible that someone (another authenticated user) could figure out how we are retrieving our data, and access other users' tasks.

I know Rules Are Not Filters (see this too), but it seems reasonable that one would want to secure data access in roughly this way.

My questions:

• Is this simply not a meaningful security concern?
• If it is, is there a Firebase-like way to do what I'm describing? In Firebase's security example, it would be like users wouldn't be able to access all rooms or messages. That seems like a perfectly reasonable software design decision (private rooms, messages in private rooms, etc.)
• Am I just totally missing something here, or not understanding the situation, or architecting this in a very naïve way?

Edit:

I think the first time I read I Structuring Data, I missed "Using Indices to Define Complex Relationships", which addresses this point.

Answer 1

I think the first time I read I Structuring Data, I missed "Using Indices to Define Complex Relationships", which addresses this point.

What I want to do here is, as Frank van Puffelen clarifies, on my various user objects, add a list of keys for items that each user can access.

This won't change much (except duplicating storing these relationships) when I update or upload items.

When fetching and listening for .ChildChanged events, however, I think instead of setting up one observeEventType handler for all of one type of object, I'll have one handler for each individual object a user has access to.