2

As mentioned here, in the specific scenario of having Groups with private files, it looks like there is really no "good" solution to use Storage Security Rules without using User Claims. There are some workarounds in that thread though, but aren't good solutions for my case.

So I was wondering, if I add an UUID as post-fix to the file paths (which I currently do for uniqueness, e.g. groups/{groupId}/images/{imageId}/imageName-{UUID}.png), could it work as a way of security through obscurity? (it would be very hard to brute-guess, making sort of a "private" file).

I know it's not ideal, but at least it's something for the time being until Firebase implements a better solution for this scenario, and be able to sleep better at night :P

My idea is to set something like:

  • list: don't allow (to give "obscurity")
  • get, create: only auth users
  • update, delete: don't allow (only with the Admin SDK)

Does my idea make sense? Or am I missing something?

ernewston
  • 923
  • 6
  • 22

1 Answers1

3

Requiring a client to know a secret string is security through obscurity, yes.

If you're allowing create access, and expecting the client app to generate the UUID, that seems like its own security (or data integrity) problem, since the client is not actually obliged to do follow any naming conventions, and it's not possible to write a rule to enforce that.

You could force the client to create the object by first calling an HTTP function, having the function create the file (empty), returning the path that was created. Then the client can upload the actual content on top of it using the returned path.

You could instead write a Storage trigger to make sure the client wrote something "secure" in the path after the fact. But the best security never trusts the client will ever do the right thing.

Doug Stevenson
  • 297,357
  • 32
  • 422
  • 441
  • Awesome to get such fast responses :D. `create` is open for auth users yes, but all file paths are mapped to Firestore (which has the proper rules). And yes, the client can upload anything without mapping to firestore, but it would not impact other users, bc it's not mapped into Firestore. I think it would only impact my billing. I can also trigger a Function on `create` to check if it's valid, if not, I can delete the file and report it. I think I can live with this approach for now. My main concern is to maintain `get` files private, and to keep others from modify/delete them. Thanks again! – ernewston Nov 30 '19 at 00:31