Common Mistakes in Firebase Security Rules | Hacker News Reader

Common Mistakes in Firebase Security Rules

medium.com

60 pointskedmi14 comments

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

How were you thinking of it before? This reads to me how Apache servers have been configured for 20 years.

Like some other commenters here. Like the rules would cascade down similar to css. You might think that a read rule on a parent node would apply to a child unless that child overrode the that rule. But it doesn't. So you keep having to read the rules up the hierarchy to see who could ever read the node.

Sounds like the functionality we see configured in e.g. .htaccess files.

This 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!

I'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?

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.

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.

Picture a tree in which the roots contain protected data and the leaves contain public data. The further you go in the direction of the roots, the more certification you need.

Cascade is the worst possible word to use for someone coming from a CSS background. From the very beginning of CSS history, cascading was tied to a notion of specificity - if you have a rule for h1 it overrides what was in the html rule. https://css-tricks.com/look-back-history-css/

But whatever Firebase is doing, it’s the opposite of specificity - it’s closer to “search top down until we find something truthy then stop.” https://firebase.google.com/docs/database/security/

This is simpler and more efficient to implement and run at scale. But imagine if styling worked like that - you could never have colored overlays, or anything we take for granted.

When over-eager marketing speak encourages insecurity, it’s a significant ethical breach.

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

have you tried Firestore? meant to solve exactly this complaint about firebase. but of coure not gonna beat a more customizable solution

Does this apply to data store though?

Reply on news.ycombinator.com