I read this book quite recently. As others have said, it's a great book. However it also had the unintended consequence of putting me off both client and server web development for life. I'm fairly sure I would never be able to write something that was secure. There's far too much to get right, too many things that could go wrong, and I'm quite sure the knowledge you need expands almost daily.
* framework - use popular, battery-tested framework. Avoid new shiny HN front-page framework for production. If you want to experiment with it, and eventually replace the old framework, then wait until the community is strong enough.
* frontend - mostly HTML/CSS/JS, we carry too much legacy baggage: years of hacks and workarounds in the spec and in implementation. Make smart use of CSP.
* backend - quite stable these days if you first take care of your server. However, sanitizing inputs and outputs is both context-sensitive and challenging. Don't forget about sandboxing, authorization and state eviction, and keys management (api keys, user keys, server keys, automation keys such as Jenkins credentials).
* package management - there are vendors and SaaS (Github, and I think Gitlab too?) provide alerts and reports on software dependencies updates, so we are doing slightly better in this area.
The entire stack of an application is not as simple as putting a pipe system together, indeed.
Postgres recently(ish)[1] got support for row level security, so with a bit of work, it's actually possible to be fairly strict on data access - but it requires at least the creation of "group level" postgres users in the db - while people will still happily allow the webserver to connect with super user privileges to the db, and write their own access controls (or use a framework that's also will be) that'll be much poorer than what's already in db, because using that is "complex".
Yeah, proper authorization is complex.
With that mindset, I'll not be surprised if people just send raw json to the client and "filter access" in javascript...
I agree about using a battle-tested framework. But there’s also risks in using a feature-rich, complex framework that you don’t have a deep understanding of. Those frameworks ease development by making decisions and doing things for you, but also by hiding things from you. Your code and its assumptions, combined with some piece of ‘magic’ deep in the framework with its own assumptions that you were not aware of, could very well give birth to a security problem.
I would say to use frameworks to your advantage, but remember to look under the hood. There’s no substitute for understanding the entire stack and knowing what your tools are doing.
Also recently finished this book as well, and it convinced me the web is secured by popsicle sticks and glue and I’m in wonder as to why everything isn’t hacked all the time.
It is largely "secured" by chewing gum, duct tape and other such things.
Some aspects have gotten better. Flash is dying, for example, and that's a huge help (I remember when the email showed up in my inbox from the Rails team, passing along that Google had informed them the same-origin sandbox was broken thanks to a Flash bug...).
Other aspects have gotten worse. The sheer number of new APIs in browsers, accessible via JavaScript, is frightening. And plenty of the problematic old ones are still around too. Plus ways to turn security features into privacy invasions (like the HSTS supercookie, which is both cool and makes me want to quit everything forever).
