27 ms·

I worked at Firebase for many years and the concerns with security rules have always plagued the product. We tried a lot of approaches (self expiring default ru

• xyzeva 3y ago
  We tried to contact google, via support to try to help or for them to help disclose the issues to the websites. We got no response other then a response telling us that they will be creating a feature request on our behalf if we wanted instead of helping us, which is fair as I think we'd have to escalate pretty far up in Firebase to get the attention of someone who could alert project owners.
  • abeisgreat 3y ago
    One of the things we fought for, for years after acquisition was to maintain a qualified staff of fulltime, highly paid support people who are capable of identifying and escalating issues like this with common sense. This is a battle we slowly lost. It started with all of support being the original team, then went to 3-4 fulltime staff plus some contracts, to entirely contractors (as far as I’m aware). This was a big sticking point for me. I told them I did not believe we should outsource support, but they did not believe we should have support for developer products at all, so I lost to that “compromise.” After that I volunteered myself to do the training of the support teams, which involved traveling to Manila, Japan and Mexico regularly. This did help but like support as whole, it was a losing battle and quality has declined over time. Your experience is definitely expected and perhaps even by design. Sadly this is true across Google, if you want help you’d best know a Googler.
    • andybak 3y ago
      > they did not believe we should have support for developer products at all That explains a lot.
      • xyzeva 2y ago
        What'd you expect, its google!
    • GuB-42 3y ago
      I suspect it is going to end up being Google's downfall, or at least, be part of it. They simply don't know humans. Their repeated failures at building social networks is good enough evidence. They always try to have the human out of the loop, which, to be fair, worked for them in the early days, as their search engine was better than those that relied on human-made directories. But now it is becoming ridiculous. It is a company of bots, for bots. And when they need humans for some reason, they take away most of the value they can add with rigid frameworks, basically treating them like bots. They pay hundreds of thousands not for people who are competent and trustworthy to provide the best service, but instead, to people who write bots to provide mediocre service. I believe that at some point, a startup who understand humans will eat them up, bit by bit, by feeding on dissatisfied customers who don't want to deal with stupid bots.
      • xyzeva 3y ago
        I really doubt that this will be google's downfall, theyre too big to fall right now. I think it will be laws.
        • withinboredom 3y ago
          The bigger they are, the harder they fall; is a saying for a reason. There is no such thing as “too big to fail” otherwise the East India Trading Company would still be in operation.
          • 3y ago
  • 0xdeadbeefbabe 3y ago
    > which is fair as I think we'd have to escalate pretty far up in Firebase to get the attention of someone who could alert project owners. This begs the question, isn't this a security vulnerability after all?
    • xyzeva 2y ago
      It is for the sites, not Firebase.
• mistrial9 3y ago
  very well spoken arguments for a fundemental need for structural diversity, not monoculture, on the net
  • brazzy 3y ago
    I don't see the comment arguing for that at all, and I don't think the analogy to crop monocultures being more vulnerable to pests really holds. There are good reasons we deride "security through obscurity" as valid, and just because "structural diversity" makes automated scanning harder doesn't mean it can't be done. See Shodan.
    • mananaysiempre 3y ago
      The idea as I (who is not GP) see it is not that diversity makes scanning harder, it’s that it makes the blast radius smaller. Notably, though, that means we have to be talking about diversity of implementations, not just deployments—numerous deployments of just a few pieces of software can be problematic in their own ways, and of course there have been bugs with huge consequences in Apache, MSRPC, or—dare I say it—sendmail since the very earliest days.
    • 0xdeadbeefbabe 3y ago
      "security through obscurity" is red team trash talk mostly.
• andenacitelli 3y ago
  It also makes portability a pain. Switching from an app with Firebase calls littered through the frontend and data consistency issues to something like Postgres is a lengthy process.
• supriyo-biswas 3y ago
  To be honest I've always found the model of a frontend being able to write data into a database highly suspect, even with security rules. Unlike a backend where where the rules for validation and security are visible and part of the specifications, Firebase's security rules is something one can easily forget as it's a separate process, and has to be reevaluated as part of every new feature developed.
  • winwang 3y ago
    Are you suggesting that it's essentially too easy for a dev to just set and forget? That's a pretty interesting viewpoint. Not sure how any BaaS could solve that human factor.
    • deleted 3y ago
      [deleted]
    • chavesn 3y ago
      I think it's more like there's more surface area to forget when you have humans handling so many concerns, and it's not likely the part that's changed the most so it's a likely candidate for being "pushed out of the buffer" (of the human). In a more typical model, backend devs focus more on security, while not needing to know the frontend, and vice versa.
    • supriyo-biswas 3y ago
      You could either do away with the model of the frontend writing to the DB and ask customers to implement a small backend with a serverless component like AWS Lambda or Google Cloud Functions. Barring that, perhaps Firestore could introduce the concept of a "lightweight database function hook" akin to Cloudflare workers that runs in the lifecycle of a DB request, thus formalizing the security requirements specific to the business requirement and causing the development organization to allocate resources to its upkeep. So while a security rule usually gets tested very lightly, you'd see far more testing in a code component like the one I'm suggesting.
      • 3y ago
• seanwilson 3y ago
  Looking at https://firebase.google.com/docs/rules/basics https://firebase.google.com/docs/rules/basics, would it be practical to have a "simple security mode" where you can only select from preset security rule templates? (like "Content-owner only" access or "Attribute-based and Role-based" access from the article) Do most apps need really custom rules or they tend to follow similar patterns that would be covered by templates? A big problem with writing security rules is that almost any mistake is going to be a security problem so you really don't want to touch it if you don't have to. It's also really obvious when the security rules are locked down too much because your app won't function, but really non-obvious when the security rules are too open unless you probe for too much access. Related idea: force the dev to write test case examples for each security rule where the security rule will deny access.
  • deleted 3y ago
    [deleted]
• Logykk 3y ago
  I view the issue as more of a poor UX choice than anything else. Firebase's interface consists entirely of user-friendly sliders and toggles EXCEPT for the security rules, which is just a flimsy config file. I can understand why newer devs might avoid editing the rules as much as possible and set the bare minimum required to make warnings go away, regardless of whether they're actually secure or not. There should be a more graphical and user-friendly way to set security rules, and devs should be REQUIRED to recheck and confirm them before any other changes can be applied.
• nness 3y ago
  I've been an advocate for Firebase and Firestore for a while — but will agree to all of these points above. It's a conceptual model that is not sufficiently explained. How we talk about it on own projects is that each collection should have a conceptual security profile, i.e. is it public, user data, public-but-auth-only, admin-only, etc. and then use the security rule functions to enforce these categories — instead of writing a bespoke set of conditions for each collection. Thinking about security per-collection instead of per-field mitigates mixing security intent on a single document. If the collection is public, it should not contain any fields that are not public, etc. Firestore triggers can help replicate data as needed from sensitive contexts to public contexts (but never back.) The problem with this approach is that we need to document the intent of the rules outside of the rules themselves, which makes it easy to incorrectly apply the rules. In the past, writing tests was also a pain — but that has improved a lot.
• kjuulh 3y ago
  The security rules where I fell off my love with Firebase, not that there is anything wrong with the security, but until the point of having to write those security rules, the product experience felt magical, so easy to use, only one app to maintain pretty much. But with the firebase security rules, I now pretty much have half of a server implemented to get the rules working properly, especially for more complex lookups. And for those rules, the tooling simply wasn't as great as using typescript or the likes. I haven't used firebase in years tho, so I don't know if it has gotten easier.
• markhalonen 3y ago
  at Steelhead we use RLS (row level security) to secure multi-tenant Postgres DB. Coolest check we do is create a new Tenant and dbdump with RLS enabled and ensure the dump is empty. Validates all security policies in 1 fell swoop.
• mh8h 3y ago
  It's not that difficult to build the scanner into the firebase dashboard. Ask the developer to provide their website address, do a basic scanning to find the common vulnerability cases, and warn them.
  • abeisgreat 3y ago
    Firebase does that, the problem is "warning them" isn't as simple as it sounds. Developers ignore automated emails and they rarely if ever open the dashboard. Figuring out how to contact the developers using the platform (and get them to care) has been an issue with every developer tool I've worked on.
• ben_jones 3y ago
  Firebase attracts teams that don’t have the experience to stand up a traditional database - which at this point is a much lower bar thanks to tools like RDS. That is a giant strobing red light of a warning for what security expectations should be for the average setup. No matter what genius features the Firebase team may create this was always going to be a support and education battle that Google wasn’t going to fully commit to
• cryptonector 3y ago
  Firebase needs something like RLS (row-level security). It needs to be real easy to write authorization rules in the database, in SQL (or similar), if you're going to have apps that directly access the database instead of accessing it via a proxy that implements authorization rules.
  • xyzeva 2y ago
    I agree! Supabase does it pretty good.
• piotrkaminski 3y ago
  One simple trick helped us a lot: we have a rules transpiler (fireplan) that adds a default "$other": {".read": false, ".write": false} rule to _every_ property. This makes it so that any new fields must be added explicitly, making it all but impossible to unknowingly "inherit" an existing rule for new values. (If you do need a more permissive schema in some places you can override this, of course.) Our use of Firebase dates back 10+ years so maybe the modern rules tools also do this, I don't know. What would really help us, though, would be: 1. Built-in support for renaming fields / restructuring data in the face of a range of client versions over which we have little control. As it is, it's really hard to make any non-backwards-compatible changes to the schema. 2. Some way to write lightweight tests for the rules that avoids bringing up a database (emulated or otherwise). 3. Better debugging information when rules fail in production. IMHO every failure should be logged along with _all_ the values accessed by the rule, otherwise it's very hard to debug transient failures caused by changing data.