4 ms·

I'm a fan of rolling actual databases, but please don't blame Firebase. The is completely the fault of the people who made that app. They have no fucking idea

I'm a fan of rolling actual databases, but please don't blame Firebase. The is completely the fault of the people who made that app. They have no fucking idea how to build systems if they can't figure out how to lock down Firebase. It isn't that hard. Source: Multiple Firebase apps back in the day.

tbrownaw 1y ago
No, hazardous defaults can be a source of fault for the entity providing them.
- moomoo11 1y ago
  Ok but it’s not like pg can’t stop you from doing something dumb. There are probably countless new projects today that are storing plaintext passwords, or not adding scoping, and so on. Putting in scopes and ensuring data security for both users and system wide is on the developer.
  - frollogaston 1y ago
    It's hard to screw up Postgres to the extent that your entire DB is made fully accessible by all users. This has happened many times with Firebase apps, for over a decade. You could have a SQL injection vuln, but any SQL lib will very clearly steer you to parameterized queries, and even then such a vuln takes some expertise to find and exploit.
    - moomoo11 1y ago
      That’s simply not true. I remember working with a startup founder who had Jerry rigged some crap shit together with gpt a year ago. I was able to access his data by simply accessing it figuring out his URL and other stuff. I told him to use supabase or DO deployment and set up proper roles and stuff… I think you’re being way too charitable honestly and it’s dangerous. I won’t join you on that path of absolving the developer of any blame. They don’t read the docs and they didn’t care simply put. Any production system needs to be tested especially if it will have PII data.
      - frollogaston 1y ago
        Don't get me wrong, there is still such a thing as a bad dev. If this startup founder actually wrote an entire app using GPT and it had such vulns, I'm pretty sure he'd mess up the Firebase ACLs too.
BoorishBears 1y ago
I blame Firebase, this is the 2nd app I saw get owned this way in the last 2 weeks, similar complete break-in including user data
- moomoo11 1y ago
  Their docs literally show how to prevent this. It’s part of the tutorial even iirc. But sure blame firebase lol
  - frollogaston 1y ago
    The variable here is Firebase, the same devs don't have these issues on other platforms. If users are reading and fully understanding the manual before setting things up, that's great, it can be default-deny and tell them how to selectively open things.
    - moomoo11 1y ago
      Again simply not true. Sorry I’m gonna move on. Y’all can continue making excuses for people leaking PII. Peace.
      - BoorishBears 1y ago
        One day, if you're lucky enough to engineer a quality product with scale, you'll realize why "they're holding it wrong" is generally a poorly received explanation, even if you're Steve Jobs.
        moomoo11 1y ago
        I mean I already have a cushy IPO exit under my belt as a lead platform engineer. So yeah already did it, global b2b product used by millions daily. I have nothing to prove anymore besides my current company that I’m doing on my own. Everyone else can do whatever insignificant and make mistakes that’s on them.
gypak 1y ago
You are absolutely correct. The founder of Tea app has only 6mo of coding bootcamp under his belt. That should explain pretty much everything that happened.

tbrownaw 1y ago

No, hazardous defaults can be a source of fault for the entity providing them.

moomoo11 1y ago
Ok but it’s not like pg can’t stop you from doing something dumb. There are probably countless new projects today that are storing plaintext passwords, or not adding scoping, and so on. Putting in scopes and ensuring data security for both users and system wide is on the developer.
- frollogaston 1y ago
  It's hard to screw up Postgres to the extent that your entire DB is made fully accessible by all users. This has happened many times with Firebase apps, for over a decade. You could have a SQL injection vuln, but any SQL lib will very clearly steer you to parameterized queries, and even then such a vuln takes some expertise to find and exploit.
  - moomoo11 1y ago
    That’s simply not true. I remember working with a startup founder who had Jerry rigged some crap shit together with gpt a year ago. I was able to access his data by simply accessing it figuring out his URL and other stuff. I told him to use supabase or DO deployment and set up proper roles and stuff… I think you’re being way too charitable honestly and it’s dangerous. I won’t join you on that path of absolving the developer of any blame. They don’t read the docs and they didn’t care simply put. Any production system needs to be tested especially if it will have PII data.
    - frollogaston 1y ago
      Don't get me wrong, there is still such a thing as a bad dev. If this startup founder actually wrote an entire app using GPT and it had such vulns, I'm pretty sure he'd mess up the Firebase ACLs too.

BoorishBears 1y ago

I blame Firebase, this is the 2nd app I saw get owned this way in the last 2 weeks, similar complete break-in including user data

moomoo11 1y ago
Their docs literally show how to prevent this. It’s part of the tutorial even iirc. But sure blame firebase lol
- frollogaston 1y ago
  The variable here is Firebase, the same devs don't have these issues on other platforms. If users are reading and fully understanding the manual before setting things up, that's great, it can be default-deny and tell them how to selectively open things.
  - moomoo11 1y ago
    Again simply not true. Sorry I’m gonna move on. Y’all can continue making excuses for people leaking PII. Peace.
    - BoorishBears 1y ago
      One day, if you're lucky enough to engineer a quality product with scale, you'll realize why "they're holding it wrong" is generally a poorly received explanation, even if you're Steve Jobs.
      - moomoo11 1y ago
        I mean I already have a cushy IPO exit under my belt as a lead platform engineer. So yeah already did it, global b2b product used by millions daily. I have nothing to prove anymore besides my current company that I’m doing on my own. Everyone else can do whatever insignificant and make mistakes that’s on them.

gypak 1y ago

You are absolutely correct. The founder of Tea app has only 6mo of coding bootcamp under his belt. That should explain pretty much everything that happened.