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
