Comment by ko_pivot

Comment by ko_pivot 10 months ago

This is such a fantastic bug. Firebase security rules (like with other BaaS systems like Firebase) have this weird default that is hard to describe. Basically, if I write my own API, I will set the userId of the record (a 'boost' in this case) to the userId from the session, rather than passing it in the request payload. It would never even occur to a developer writing their own API past a certain level of experience to let the client pass (what is supposed to be) their own userId to a protected API route.

On the other hand, with security rules you are trying to imagine every possible misuse of the system regardless of what its programmed use actually is.

nottorp 10 months ago

> On the other hand, with security rules you are trying to imagine every possible misuse of the system regardless of what its programmed use actually is.

Tbh you're doing it wrong if you go that way.

Default deny, and then you only have to imagine the legitimate uses.

Reply View 3 replies

ko_pivot 10 months ago

Fair enough, but my point is more conceptual, in that you still have to write `boost.userId == auth.userId` as an allowed pattern rather than making that pattern the only technically possible result, which is the convention in a traditional API.

Reply View | 1 reply
- dwattttt 10 months ago
  
  The failure modes are much clearer: when you write the API in a default-deny context & forget to add that allowed pattern, it never works, so you notice & figure out the bug.
  The same story with default-allow means the system looks like it works fine, and you end up with no security at all.
  
  Reply View | 0 replies
sorrythanks 10 months ago

And then when you imagine the legitimate uses you have to imagine how allowing those legitimate uses could be misused. You always need to think red and blue.

Reply View | 0 replies

kevincox 10 months ago

For inserts yes, but for updates I've frequently seen cases where people just stuff the whole request into their ORM or document store. It is pretty easy to think "the owner can update the document" without realizing that there are some fields (that the official client doesn't set) that shouldn't be updated (like the owner or created timestamp).

The correct solution is likely default-deny auth for every single field. Then you at least have to explicitly make the owner field writable, and hopefully consider the impact of transfering this object to another user.

Reply View 0 replies