I just want to call out that there is a lot of blame put on firebase here in the comments but I think that's just people parroting stuff they don't actually know about (I don't use firebase, I have tried it out in the past though). This isn't some edge case or hard to solve thing in firebase, this is the easy stuff.
The real issue here is that someone wrote an api that trusted the client to tell it who they were. At the end of the day this is an amateur mistake that likely took a 1 line diff to fix. Don't believe me? Check out the docs: https://firebase.google.com/docs/rules/rules-and-auth#cloud-... - `request.auth` gives you the user id you need (`request.auth.uid`).
As someone with an app built on firebase, yes. As the author rightly points out, it's very easy to misconfigure, but basic security practices like these are highlighted in bright, bold warning text in the Firebase docs.
Security rules are meant to be taken seriously, and it's your only line of defense.
Unfortunately, we currently have an industry where highly paid "engineers" unironically believe that their job can be done by reading/watching random tutorials, googling for StackOverflow answers, and pasting code from gists.
Attentively reading documentation or developing a mental model of how your tools work so that you know how they are built to be handled does not make it on to any job listing bullet points. It presumably fell off the bottom in favor of team spirit or brand enthusiasm or whatever.
How many tutorials, community answers, and gists do you think conveyed that warning?
Reading/watching random tutorials and asking basic questions on SO __instead of reading the official docs__ is a trend I've observed for the last 10 years. Even for stuff pretty well documented like Python, Postgres, React, etc.
Most official documentation is awful, and just an API reference. It's (almost) like asking someone to learn english and then pointing them to a dictionary.
And that's because a lot of devs think it's perfectly dandy to just put perfunctory docstrings in their methods, point it at whatever "doc generation" tool, wire it up to a github.io domain and call it a day.
There is a reason people crave, want and seek things like SO and blog-posts. They're packed full of insight, working examples and just plain old "how TF do you use this thing". Oh and of course, the "this problem A didn't work when using setup B and C, and that's because of reasons X,Y,Z. Here, try H,I & K and it'll work.
This goes doubly so for google cloud documentation. Firebase docs are decent, but if you're a developer who's gotten used to google's documentation style I could see skipping right over it.
For many years entire sections across multiple pages of firebase's documentation were missing after the site contents had been migrated from one system to another.
Multiple years of sample code and examples just cut out from the middle of pages.
When I was building on firebase it took me a long time to reconstruct exactly how certain aspects of the system were supposed to work just because of those missing docs.
I remember writing a Twitter library when that was a thing, and being severely disappointed at the quality of the API documentation. There seemed to be little choice other than to experiment to see what responses you’d receive (and hope that it wouldn’t change underneath you). Same was often true with some of the GitHub APIs, although it’s been a few years since I’ve spent time with them.
I often wonder how much this can be attributed to the pretty awful SEO of most documentation. I write mostly Python at work and it's infuriating how often GeeksForGeeks, W3Schools, Programiz, or RealPython pop up when I'm just trying to reference like, the arg order of a builtin, or the particular behavior. Django is worse, I often feel like I can't even find the doc when I know it's there and read it before.
Documentation is largely static content. It isn't their job to play SEO games to convince search engines to surface it in the query results. Documentation is not a revenue generator for Google so it gets buried below the sites with Doubleclick ads.
Attempting to find the relevant docs page via search engines is generally not a good way to go, you should go to the documentation and search from there. Bookmark the landing page of the documentation.
People have already given many ideas, but if you use DuckDuckGo they have bangs for searching various python docs. Here's a page that lets you search which ones are available: https://duckduckgo.com/bangs
For sure, I think the issue is – at what point in an engineer's development is that fact hammered home? For me it was hanging out with friends and learning fundamentals together, and then even more reinforced in the security course I took in college. For others, they might skip that elective in school (or their bootcamp will gloss over it), and they learn it the hard way later on the job?
That said, ideally code review/peer review/design review would catch things like this. If this was a feature implemented by an engineer that wouldn't know any better, they should have at least some help from others around them.
The issue is not about supporting engineers, this isn’t a pile-on to some poor engineer. It’s about choosing secure software, and avoiding software (particularly critical and vulnerable software like a web browser) from orgs that have built severe vulnerabilities into their software by incorrectly implementing something foundational to computer security.
There are many smart engineers who I would not trust to build my web browser because they lack the domain knowledge to do so. That’s not a slight on them. But if a company hired those people to make a web browser, I wouldn’t trust that org’s software.
This wasn't really a problem that required domain-specific knowledge to get right. Whoever designed an API that allows the client to bypass auth like that can't be trusted to design software that takes user input. At least not without some additional training that was missed along the way.
It points to a deeper issue in the Browser Company imo. Clearly, an inexperienced dev wrote that api, a senior approved the PR and no one in the wider team picked it up. And that's a team building the fundamental unit of your digital experience. If they failed at something this basic, I would be terrified to know what else they are missing in terms of security
This may or may not be fair, but in my view, the type of person that would opt for a firebase solution is probably the type of person most vulnerable to foot guns.
Sadly true, but Firestore has a security rules emulator and encourages you to write unit tests for it! There's just so many levels of "ignored all reasonable practices" here. Where's the code review? Where's the security/privacy audit?
I am glad to put engineers in quotes because many people here and elsewhere will use that word with a straight face while also believing that you can call yourself that while learning your job from watching youtube vids and pasting code you don't understand. We need to stop using the word "engineer" for "software developer".
I shall watch the downvotes come from these so called "engineers".
I think a system that makes it this easy to shoot yourself in the foot is probably not a great system. Documentation is important, and I'm glad it's clear and obvious, but humans make mistakes. You'd hope that the mistakes have less dire consequences.
> it's very easy to misconfigure, but basic security practices like these are highlighted in bright, bold warning text in the Firebase docs.
I'm sorry but if the whole design is "one big database shared with everyone and we must manually configure the database for auth" there is a problem that's deeper than just having to read the doc. It means the basic understanding of what it means to keep data as private as possible is not understood. A shared database only works when the server accesses it, not when client has direct access.
What Arc needs is to segregate each user's data in a different place, in the design of the database, not as part of configuration of custom code. Make it impossible to list all user's data, or even users. When, not if, an id is guessed, related data becomes accessible by someone else; make it so that someone else still can't read it, or can't replace it.
Nobody reads docs dude. They copy and paste stack overflow answers, and now, copilot answers, which is going to be based on stack overflow ultimately anyway.
I have heard this said by many people: “I don’t look at documentation because it usually is inaccurate/out of date”
There’s plenty of people sharing anecdata about bad docs, and I’ve dealt with my fair share. But my anecdata is that engineers who habitually go to the docs directly and read them gain a better understanding and write better software than those who do not. I believe that most software for engineers has documentation that is more informative than stack overflow and blog posts.
I support reading docs first for questions, but man some truly are terrible.
Like cmake. This just vomits a dissertation at you for each function without really ever saying what it does or how to use it. That’s why there’s so many different sites and GitHub repos with samples. 95% of which are completely out of date (which is a problem cause people looking for these samples probably aren’t on the ups with being able to tell if they’re out of date)
It's interesting to see software engineers going from rolling their own auth, to not rolling their own auth, to not even noticing this quite blatant security problem.
It doesn't matter if you roll your own auth or not, you need to understand a very basic fundamental of it all: never trust the client.
Coworker implies paid work, and therefore they are not amateurs. They very well may make the same mistakes, but those mistakes would be professional mistakes.
Why this level of pedantry when the meaning is absolutely clear? A professional can make an amateur mistake. This makes perfect sense. That isn't implying the professional is actually an amateur, but that he made a mistake that an amateur would make.
For some added pedantry: aren't all the mistakes that a professional might make, also ones an amateur would make?
In fact, it seems like an amateur is likely to run into all mistakes more often, thereby making all mistakes amateur mistakes; unless there some class of mistake that amateurs are better at avoiding?
YES!!! You need auth to prevent employees from looking up sensitive user data without a good reason, or it'll be a stalker's haven. And to prevent possible intruders from gaining more data/access. Defense in depth. And for preventing an experiment from wiping use data. And for so many other reasons!
> If it's internal, did they really need to have auth?
Nothing on a network is truly internal. The moment you break the physical link between metal and man you're in an unintuitive, and thus insecure, state.
Agreed, if I understand correctly the fix to this issue would be the following rules inside of a "match" statement in firestore.rules which is plainly documented as firebase firestore security 101:
```
// Allow create new object if user is authenticated
allow create: if request.auth != null;
// Allow update or delete document if user is owner of document
allow update, delete: if request.auth.uid == resource.data.ownerUID
Unclear if they had these rules in place already but I'm curious... If the rule permits writing when the userid matches, presumably there is nothing stopping the write operation to change the userid value, to your point.
Which then leads me to the next question, what is the practical way to write rules against that operation?
In my limited experience, I've seen it handled by adding the user's ID in the path of any resource that belongs to a particular user, so that the user ID from the resource path can be compared with the authenticated user ID as a security rule condition.
This is what happens when you hire solely based on leetcode skill. A shit-tier engineer can master leetcode within months, but a good engineer will probably struggle at Find Nth Smallest Sum problem because he spends more time reading and thinking about code.
Leetcode is a fucking joke to the industry, gone are the days when you actually had good code with devs who spent time thinking about information architecture. In my experience boomer devs are actually the only ones who write idiomatic code. Millennial and Gen-z devs are the worst, they have no understanding beyond basic function calling.
the whole idea of firebase is flawed as logic that belongs to a server is now on the client side. I don't know much about security but that sounds like making any centralized rule (eg security) hard to implement. It also tends to expose more internal logic than the client needs to know, which is bad in both software design and security.
The real issue here is that someone wrote an api that trusted the client to tell it who they were. At the end of the day this is an amateur mistake that likely took a 1 line diff to fix. Don't believe me? Check out the docs: https://firebase.google.com/docs/rules/rules-and-auth#cloud-... - `request.auth` gives you the user id you need (`request.auth.uid`).