Common Mistakes in Firebase Security Rules
1–10 of 16 posts
Re: Common Mistakes in Firebase Security Rules
#2I'm not familiar with firebase, but am I reading correctly that rules cascade but without specificity rules?
How does cascading make sense at all if lower-down rules don't supersede higher rules?
Re: Common Mistakes in Firebase Security Rules
#3I'm not familiar with firebase, but am I reading correctly that rules cascade but without specificity rules? How does cascading make sense at all if lower-down rules don't supersede higher rules?
Agreed - this doesn't seem to make sense to me. And the docs seem to corroborate this:
> Note that .read and .write rules shallower in the database override deeper rules, so read access to /foo/bar/baz would still be granted in this example even if a rule at the path /foo/bar/baz evaluated to false.
https://firebase.google.com/docs/database/security/
This seems unreasonable at first glance. Does anyone know the rationale for it?
Re: Common Mistakes in Firebase Security Rules
#4I'm not familiar with firebase, but am I reading correctly that rules cascade but without specificity rules? How does cascading make sense at all if lower-down rules don't supersede higher rules?
Agreed - this doesn't seem to make sense to me. And the docs seem to corroborate this: > Note that .read and .write rules shallower in the database override deeper rules, so read access to /foo/bar/baz would still be granted in this example even if a rule at the path /foo/bar/baz evaluated to false. https://firebase.google.com/docs/database/security/ This seems unreasonable at first glance. Does anyone know the ratio…
[deleted]
Re: Common Mistakes in Firebase Security Rules
#5I'm not familiar with firebase, but am I reading correctly that rules cascade but without specificity rules? How does cascading make sense at all if lower-down rules don't supersede higher rules?
This isn't CSS, its a well documented behavior of Firebase Realtime Database because its "just" nested JSON. if you request one node in the JSON and it passes a security rule it gives you the entire node. Having to traverse all children for additional rules would be less performant.
I do think that if this is such a common behavior the rules DSL could be revised so that fewer people fall down the "pit of success". At the very least do not allow people to define rules that have already been defined by parents. This should be part of Firebase, the fact that theres a startup providing this service is the biggest code smell I can think of telling you there's a problem here.
Re: Common Mistakes in Firebase Security Rules
#6I'm not familiar with firebase, but am I reading correctly that rules cascade but without specificity rules? How does cascading make sense at all if lower-down rules don't supersede higher rules?
Agreed - this doesn't seem to make sense to me. And the docs seem to corroborate this: > Note that .read and .write rules shallower in the database override deeper rules, so read access to /foo/bar/baz would still be granted in this example even if a rule at the path /foo/bar/baz evaluated to false. https://firebase.google.com/docs/database/security/ This seems unreasonable at first glance. Does anyone know the ratio…
I dont speak for the firebase team but this is my rationale: its "just" nested JSON. if you request one node in the JSON and it passes a security rule it gives you the entire node. Having to traverse all children for additional rules would be less performant.
Re: Common Mistakes in Firebase Security Rules
#7This article is fantastic for people that are more new to Firebase and make these common mistakes. I know when I first started using Firebase for side projects (for fun), as just a front-end dev using Firebase, I found the security aspect of Firebase very overwhelming and scary. I ended up having to pull in some dev friends to help me dial them in properly. The Firebase security docs may be way better now but even as little as a year ago, I found them to just gloss over the topic too casually, personally. It did not make me feel super confident in the security rules I had. I really appreciate the author here taking the time to outline some of these and expand their thoughts more! It really helps a ton!
Re: Common Mistakes in Firebase Security Rules
#8This was a different way of thinking about security rules for us. But basically you have to make everything not readable and not writable at the root and then open up access farther down. And the way you need to structure your data will be affected. You might have a "user" level in the tree but you make a child level "private" readable by the actual user and no one else, like /users/$userId/private. Then you might have a /users/$userId/public that anyone can read, etc.
We also don't allow any writing directly to the data nodes but rather have a separate level in the tree where "requests" are written, then a privileged process reads, processes, and writes to the main data nodes, then notifies the client it's done by writing to a "response" node that only the client can read. This helps us make the security rules a little simpler and less error prone to mistakes, but primarily it's so we have a hook to run business processes and validation that doesn't need to be in the client which is unsafe.
I'd recommend using the bolt compiler (https://github.com/firebase/bolt) so that you can write rules using repeatable logic and so that you can actually read complex rules.
Re: Common Mistakes in Firebase Security Rules
#9I used to use Firebase. I was ecstatic about the fact that I didn’t need a server.
Then I spent months where Whenever I needed to solve a use case I’d spend more time thinking about how to structure my data, how to secure it. I’d spend a lot less time actually building features and more time twisting myself into knots figuring out how to make it work with security rules. It feels backwards to me to have security dictacte the structure of my data rather than the business needs.
I switched to Azure functions front ending my data, which resides in Cosmos DB. Now I can structure my data in a way that suits the business need. Security is incomparably easier now and more flexible.
Re: Common Mistakes in Firebase Security Rules
#10I used to use Firebase. I was ecstatic about the fact that I didn’t need a server. Then I spent months where Whenever I needed to solve a use case I’d spend more time thinking about how to structure my data, how to secure it. I’d spend a lot less time actually building features and more time twisting myself into knots figuring out how to make it work with security rules. It feels backwards to me to have security dict…
have you tried Firestore? meant to solve exactly this complaint about firebase. but of coure not gonna beat a more customizable solution