Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Common Mistakes in Firebase Security Rules

medium.com

Post reply on HN
Print view View original

11–16 of 16 posts

Re: Common Mistakes in Firebase Security Rules

#11

Post by rhizome »

realpeopleio wrote: post #8

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 ha…

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.

Re: Common Mistakes in Firebase Security Rules

#12

Post by muthdra »

throwawayReply wrote: post #2

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?

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.

Re: Common Mistakes in Firebase Security Rules

#13

Post by btown »

throwawayReply wrote: post #2

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?

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.

Re: Common Mistakes in Firebase Security Rules

#15

Post by realpeopleio »

rhizome wrote: post #11
realpeopleio wrote: post #8

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 ha…

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 ha…

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.

Re: Common Mistakes in Firebase Security Rules

#16

Post by rhizome »

realpeopleio wrote: post #15
rhizome wrote: post #11

Earlier quoted context omitted.

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 ha…

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.
Post reply on HN