Hacker News Reader

Hacker News

Comment by MattDaEskimo | Hacker News Reader

Parent Full thread

MattDaEskimo

Full permissions for a user is blatant negligence.

For anyone who's never used Firebase before this is as simple as a single piece of logic that appears basically as:

if authUserID is UserDirectoryID

That simple.

View on HN

I've never used firebase before. But are you saying that, in it's default configuration, anyone who registers a firebase account has R/W access to any firebase database as long as the database owner forgot to put that line in there somewhere?

That seems like an insane design...

No, the default is no access to anything. You have to write rules that allow access to each record in the database.

It sounds like the rule that they wrote only checked that the request _is logged in_, because they assumed that visitors can't create their own accounts.

Which, even if that assumption were true, is still bonkers, because from what I see in the article they had no partitioning between tenants or permissions checks for different user roles. So even if they hadn't accidentally allowed creating new accounts, any account on any one of their existing customers had full access to every row in the database.

> any account on any one of their existing customers had full access to every row in the database.

Correct. :/

It's mind blowing to me, as someone who's built a SAAS and then talked to customers and ultimately their CTOs and CDOs that KFC and co ended up using such a service, either they would isolate the level of data exposed to the service and trust them on their contract - and then ruin them in court, or they would require some kind of compliance like SOC2 which should at least mean the solution was pen tested, and any pen tester worth anything will immediately find firebase is part of the solution and immediately test access rules..

The fact that the company/CEO/cto seems to just get away with this is depressing, because why should anyone else? it's not good business sense to invest in security if there's no serious repercussions

Yeah, the whole design of Firebase is that the client interacts directly with Firebase, not via your server. Which makes sense for auth since you don't want to be handling that manually, but the database? That makes me uneasy.

I've seen many many firebase projects with rules disabling access only if "auth != null" instead of implementing some kind of even rudimentary access controls. It's a very dangerous habit that seems to come straight from the firebase docs[1]:

> When the user requesting access isn't signed in, the auth variable is null. You can leverage this in your rules if, for example, you want to limit read access to authenticated users — auth != null. However, we generally recommend limiting write access further.

[1]: https://firebase.google.com/docs/rules/rules-and-auth

When you create the database, you're asked whether you want to give everyone access (development mode), or whether no one gets it (production mode). If you choose the development mode, it will automatically disable that access after a certain timestamp, so you don't forget to update it before shipping. This of course doesn't stop people who don't care about security from just manually giving out public R/W, or extending the timestamp.

Reply on news.ycombinator.com