I bet supabase also have a lot of naive users who haven't enabled RLS in their postgres instances (last I checked, not enabled by default), but are nevertheless sharing api keys client side in their apps (https://supabase.com/docs/reference/javascript/initializing).
Supabase support's defense is "well, if you read the manual you'll understand how to set this up properly", but that's not how bootcamp developers tend to work.
I spent 10 minutes seeing if I could convince google or kagi to search for sites like these, but unfortunately js isn't searchable in either.
Firestore is great, especially as a cleaned up and more capable version of Datastore, but Firebases's influence on it as a successor to Firebase Realtime DB is showing in this complexity here.
IMO, the easiest and most secure thing is to not do direct DB reads and writes from your client. Use a traditional client-server architecture and have your server talk to the DB.
The times I do use the Firestore client library, it's only for reading and only for the realtime updates. My security rules disallow all writes.
I’ve used Firestore a few years back. Just checked and indeed the same vulnerability is present. Users can’t create/change submissions with a different userID but can change the userID of their own submissions, thus impersonating someone else.
Of course, that was 2021 and I had barely started programming. Not sure if I’d make the same mistake now (of using Firestore in the first place :)
What is the intent of allowing arbitrary document assignment to any other global user in the system, with zero default security checks in place? That seems like a fundamentally terrible idea. Other sharing systems require explicit steps to share documents between users (sharing a Google doc with an email address, for example), and it's a very controlled workflow. In Firestore, user IDs are global, and you can arbitrarily give them data? Even if you can get around this with specific security rules, why is this even a thing in the first place?
Kinda the opposite - Firestore documents don't inherently have a userId of the owner. Rather, they just have arbitrary fields.
Making all your documents have a `owner_uid` or `userId` field is just a convention they recommend, because it helps you write rules.
So rather: they have no default system for handling documents that can only be accessed by a given user, but rather you have to construct it using `firestore.rules`, and you end up with something oddly default-insecure.
I bet supabase also have a lot of naive users who haven't enabled RLS in their postgres instances (last I checked, not enabled by default), but are nevertheless sharing api keys client side in their apps (https://supabase.com/docs/reference/javascript/initializing).
Supabase support's defense is "well, if you read the manual you'll understand how to set this up properly", but that's not how bootcamp developers tend to work.
I spent 10 minutes seeing if I could convince google or kagi to search for sites like these, but unfortunately js isn't searchable in either.
It does at least look like their docs for the equivalent policy are not vulnerable to this attack though
https://supabase.com/docs/guides/database/postgres/row-level...
ie: The "Update Policies" DSL ensures that the user does not change the user id of a row
Supabase nags you about RLS all the time.
Firestore is great, especially as a cleaned up and more capable version of Datastore, but Firebases's influence on it as a successor to Firebase Realtime DB is showing in this complexity here.
IMO, the easiest and most secure thing is to not do direct DB reads and writes from your client. Use a traditional client-server architecture and have your server talk to the DB.
The times I do use the Firestore client library, it's only for reading and only for the realtime updates. My security rules disallow all writes.
I’ve used Firestore a few years back. Just checked and indeed the same vulnerability is present. Users can’t create/change submissions with a different userID but can change the userID of their own submissions, thus impersonating someone else.
Of course, that was 2021 and I had barely started programming. Not sure if I’d make the same mistake now (of using Firestore in the first place :)
What is the intent of allowing arbitrary document assignment to any other global user in the system, with zero default security checks in place? That seems like a fundamentally terrible idea. Other sharing systems require explicit steps to share documents between users (sharing a Google doc with an email address, for example), and it's a very controlled workflow. In Firestore, user IDs are global, and you can arbitrarily give them data? Even if you can get around this with specific security rules, why is this even a thing in the first place?
Kinda the opposite - Firestore documents don't inherently have a userId of the owner. Rather, they just have arbitrary fields.
Making all your documents have a `owner_uid` or `userId` field is just a convention they recommend, because it helps you write rules.
So rather: they have no default system for handling documents that can only be accessed by a given user, but rather you have to construct it using `firestore.rules`, and you end up with something oddly default-insecure.