问题
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 usersupdate,delete: don't allow (only with the Admin SDK)
Does my idea make sense? Or am I missing something?
回答1:
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.
来源：https://stackoverflow.com/questions/59110124/firebase-storage-security-through-obscurity