> 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.
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.
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.
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.