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