
Common Mistakes in Firebase Security Rules - kedmi
https://medium.com/noless/common-mistakes-in-firebase-security-rules-part-1-fd8cdd8bc8a6
======
realpeopleio
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](https://github.com/firebase/bolt)) so that
you can write rules using repeatable logic and so that you can actually read
complex rules.

~~~
rhizome
_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._

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

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

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

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

------
throwawayReply
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?

~~~
faitswulff
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/](https://firebase.google.com/docs/database/security/)

This seems unreasonable at first glance. Does anyone know the rationale for
it?

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

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

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

------
pspeter3
Does this apply to data store though?

