Hacker News Reader

Comment by zachrip | Hacker News Reader

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

View on HN

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.

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.

> bold warning text in the Firebase docs.

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.

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.

This is why I switched to Kagi.com it gives me results that are much more sane for things I'm looking for when it comes to a programming stance

For native documentation, why not just search the official docs at https://docs.python.org/ ?

I find it to be very discoverable if you are looking for docs about a specific function or module.

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

Also, many pieces of software whose "documentation" is just some examples of its use.

Yeah, the official docs for python rarely if ever show up on the first two pages of search unless I do `from: python.org`.

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.

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.

> Most official documentation is awful

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.

That's true but people still do it for well documented stuff like Vue, Svelte and the R that shall not be named. Two wrongs that don't make a right

Google is really good at surfacing random blogs and SO questions instead of the official docs.

"don't trust the client / validate inputs" is software security 101

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?

Nah, just ask ChatGPT.

ChatGPT would have probably parrotted the bold text. It is always super concerned about risks.

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

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.

Just with less context and review.

Maybe docs should try to be consistently more accurate, up to date, and legible than (even) stack overflow answers ¯ \ _ ( ツ ) _ / ¯

None of that matters if it doesn't show up first or second in Google results.

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

Also how does this work legally with regards to data sovereignty? Is it just a case of hoping nobody notices/complains?

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.

At the end of the day this is an amateur mistake

God I wish. More than one of my coworkers has made this exact mistake with our (thankfully internal) front-end apps.

Are you defining amateurs as people who are not your coworkers? It can still be an amateur mistake.

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?

There are probably mistakes an amateur cannot make because they can't penetrate the problems where the mistakes would be made.

That is some next-level bad faith. Impressive.

If it's internal, did they really need to have auth?

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

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!

The term of art is "Friendly fraud".

A significant amount of product stolen from retail stores actually goes out the back door.

I guess we're not always professionals at all the work that we do, if that makes sense

A security plan which depends on any person never making an amateur mistake, is an amateur mistake.

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

```

Is there no Allow-read? Edit: Yes,

    allow read, update, delete: if request.auth != null && request.auth.uid == userId;

Didn't they already have these rules in place? And the vulnerability was when the owner was updating the resource to have a new owner?

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.

But as expected, you can validate the incoming data as well https://firebase.google.com/docs/firestore/security/rules-co... but this would need to be done for any attribute that might lead to a change of ownership.

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.

Reply on news.ycombinator.com