7 ms·

I don't know what exactly happened here, but Firebase has two defaults. Test access rules which auto expire and are insecure, or production rules which require

I don't know what exactly happened here, but Firebase has two defaults. Test access rules which auto expire and are insecure, or production rules which require auth. If you do something stupid, like keep ignoring the insecure warning and updating them so they don't expire, that's your fault. In no other industry do workers blame their tools.

prophesi 2y ago
The issue usually lies in there not being enough security rules in place, not in keeping insecure rules active. For instance, for the Arc incident which we were given more information on, it was due to not having a security rule in place to prevent unauthorized users from updating the user_id on Arc Boosts in the Firestore. Go into any other industry and hear when they say, "shoot yourself in the foot", and you've likely stumbled upon a situation where they blame their tools for making it too easy to do the wrong thing.
- 999900000999 2y ago
  If you don't setup any access rules in Firebase, by default it'll deny access. This means someone setup these rules improperly. Even if, you're responsible for the tools you use. We're a bunch of people getting paid 150k+ to type. It's not out of the question to read documentation and at a minimum understand how things work. That said I don't completely disagree with you, if Firebase enables reckless behavior maybe it's not a good tool for production...
  - prophesi 2y ago
    And I don't necessarily disagree either; good callout that it _was_ about improperly configured ACL's, I meant more that it wasn't related to keeping test rules alive. For 150k+ salaries, frontend dev salaries are generally a lot less than their backend counterparts. And scrappy startups might not have cash for competitive salaries or senior engineers. I think these are a few of the reasons why Firebase becomes dangerous.
    - 999900000999 2y ago
      150k is more than a fire fighter in San Francisco. https://sf-fire.org/employment-opportunities/h2-firefighter https://sf-fire.org/employment-opportunities/h2-firefighter I don't think it's out of the question to expect professionalism at 150k. These are VC funded companies, not a couple of college kids scraping together a prototype. Then again, if I was a CTO seeing stories like this I'd be inclined to NOT use Firebase. I'm actually using Supabase right now since I don't like vendor lock in. Deploying Supabase manually is really difficult, but it is an option. I imagine if I ever run a serious company, which I don't think will ever happen, I would take something like Supabase and run it on prem with some manner of enhanced security. It's interesting though... For decades the industry has been trying to push this narrative that you don't need servers. You can handle everything using some magic platform, and throw in a couple of custom lambda functions when you need to execute logic. Parse, Firebase, Appwrite and dozens of others emerged to fill this niche. ToDesktop, provides even another layer of abstraction. We don't want to handle our own app updates, cool let someone else do it. That someone else doesn't want to manage their own backend, cool let someone else do it. You end up with multiple layers of potential vulnerabilities which shouldn't exist... Cursor, Arc, etc could run their own update servers. Maybe the solution is a Steam like distribution platform. Or just using Steam itself. That's a 30% cut to let someone else figure out your app distribution...
      - Eisenstein 2y ago
        > I don't think it's out of the question to expect professionalism at 150k. These are VC funded companies, not a couple of college kids scraping together a prototype. You can expect whatever you want, just prepare to be disappointed. We have absolutely learned by now that unless there very real consequences for doing or not doing something, you will regularly see the worst possible thing happen. This is why licenses exist and legal 'sign-offs' exist. There needs to be a licensing organization that can revoke people's ability to get certificates or to even be employed working on certain aspects of software if we ever want to solve this problem. I mean, you even need a license to cut hair in many states.
        2y ago

prophesi 2y ago

The issue usually lies in there not being enough security rules in place, not in keeping insecure rules active. For instance, for the Arc incident which we were given more information on, it was due to not having a security rule in place to prevent unauthorized users from updating the user_id on Arc Boosts in the Firestore. Go into any other industry and hear when they say, "shoot yourself in the foot", and you've likely stumbled upon a situation where they blame their tools for making it too easy to do the wrong thing.

999900000999 2y ago
If you don't setup any access rules in Firebase, by default it'll deny access. This means someone setup these rules improperly. Even if, you're responsible for the tools you use. We're a bunch of people getting paid 150k+ to type. It's not out of the question to read documentation and at a minimum understand how things work. That said I don't completely disagree with you, if Firebase enables reckless behavior maybe it's not a good tool for production...
- prophesi 2y ago
  And I don't necessarily disagree either; good callout that it _was_ about improperly configured ACL's, I meant more that it wasn't related to keeping test rules alive. For 150k+ salaries, frontend dev salaries are generally a lot less than their backend counterparts. And scrappy startups might not have cash for competitive salaries or senior engineers. I think these are a few of the reasons why Firebase becomes dangerous.
  - 999900000999 2y ago
    150k is more than a fire fighter in San Francisco. https://sf-fire.org/employment-opportunities/h2-firefighter https://sf-fire.org/employment-opportunities/h2-firefighter I don't think it's out of the question to expect professionalism at 150k. These are VC funded companies, not a couple of college kids scraping together a prototype. Then again, if I was a CTO seeing stories like this I'd be inclined to NOT use Firebase. I'm actually using Supabase right now since I don't like vendor lock in. Deploying Supabase manually is really difficult, but it is an option. I imagine if I ever run a serious company, which I don't think will ever happen, I would take something like Supabase and run it on prem with some manner of enhanced security. It's interesting though... For decades the industry has been trying to push this narrative that you don't need servers. You can handle everything using some magic platform, and throw in a couple of custom lambda functions when you need to execute logic. Parse, Firebase, Appwrite and dozens of others emerged to fill this niche. ToDesktop, provides even another layer of abstraction. We don't want to handle our own app updates, cool let someone else do it. That someone else doesn't want to manage their own backend, cool let someone else do it. You end up with multiple layers of potential vulnerabilities which shouldn't exist... Cursor, Arc, etc could run their own update servers. Maybe the solution is a Steam like distribution platform. Or just using Steam itself. That's a 30% cut to let someone else figure out your app distribution...
    - Eisenstein 2y ago
      > I don't think it's out of the question to expect professionalism at 150k. These are VC funded companies, not a couple of college kids scraping together a prototype. You can expect whatever you want, just prepare to be disappointed. We have absolutely learned by now that unless there very real consequences for doing or not doing something, you will regularly see the worst possible thing happen. This is why licenses exist and legal 'sign-offs' exist. There needs to be a licensing organization that can revoke people's ability to get certificates or to even be employed working on certain aspects of software if we ever want to solve this problem. I mean, you even need a license to cut hair in many states.
      - 2y ago