6
votes

I know there are several questions regarding this (e.g. https://stackoverflow.com/a/52808572/3481904), but I still don't have a good solution for my case.

My application has Groups, which are created/removed dynamically, and members (users) can be added/removed at anytime.

Each Group has 0..N private files (Firebase Storage), saved in different paths (all having the prefix groups/{groupId}/...).

In Firestore Security Rules, I use get() & exists() to know if the signed-in-user is part of a group. But I cannot do this in the Firebase Storage Security Rules.

The 2 proposed solution are:

  • User Claims:

but the token needs to be refreshed (signing out/in, or renewing expired token) which is not acceptable for my use case, because users need to have access immediately once invited. Also, a user can be part of many groups, which can potentially grow over 1000 bytes.

  • File Metadata:

but Groups can have N files in different paths, so I will need to loop-list all files of a group, and set the userIds of the group-members in the metadata of each file, allowing access to it. This would be an action triggered by Firestore (a Firebase Function), when a member is added/removed.

I don't like this approach because:

  • needs to loop-list N files and set metadata for each one (not very performant)
  • To add new files, I think I would need to set create to public (as there is no metadata to check against yet), and then a Function would need to be triggered to add the userIds to the metadata
  • there might be some seconds of delay to give files access, which could cause problems in my case if the user opens the group page before that time, having a bad experience

So, my questions are:

  1. Is there a better way?
  2. If I only allow the client to get and create all files when authenticated (disallowing delete and list), would this be enough for security? I think that there might be a chance that malicious hackers can upload anything with an anonymous user, or potentially read all private group files if they know the path...

Thanks!

1

1 Answers

5
votes

If custom claims don't work for you, there is really no "good" way to implement this. Your only real options are:

  • Make use of Cloud Functions in some way to mirror the relevant data from Firestore into Storage, placing Firestore document data into Storage object metadata to be checked by rules.
  • Route all access to Storage through a backend you control (could also be Cloud Functions) that performs all the relevant security checks. If you use Cloud Functions, this will not work for files whose content is greater than 10MB, as that's the limit for the size of the request and response with Cloud Functions.

Please file a feature request with Firebase support to be allow use of Firestore documents in Storage rules - it's a common request. https://support.google.com/firebase/contact/support