I would love if every web app went through proper threat modeling periodically. But we're in a fast-moving industry, and that takes time. Sometimes people need to ship and do it now, or yesterday. I'm aiming to help by helping people cover the basics and reduce the surface area of attack.

Maybe it's worth adding that the basics are just the basics, not a substitute for real threat modeling and analysis. But there's always a real-world cost/benefit factor.

The broader approach matters if you already have got the basics covered, but sadly it seems that most people don't have the basics covered at all. Most of the hacks I read about are impressive not because of their ingenuity, but because of how depressingly mundane they are. SQL injection hacks are still commonplace.

So, no, let's keep raising awareness of the basics until finally everyone gets it. Then, once the OWASP top ten is filled with MITM, timing and social engineering attacks, that's when we can move on to the broader approach.

This is true, however with creating applications with Django you are protected against most basic attacks. The ORM uses parameterized queries, all unsafe output is automatically escaped, Protection against CRLF injection within the framework and protection against HTTP response splitting.

The framework isn't fool proof (no one can protect developers from themselves). But I feel that Django does what it needs to do when it comes to protecting its users.

As long as you're using the tools provided, you're doing your due diligence. The framework provides a lot, and the ecosystem usually provides the rest.

The "last mile" is just making sure your code is using all those tools correctly.

Tools won't help when an integer overflow causes (for example) stock to be sold rather than bought.

And yet that example may only be the last item in a threat tree, which may have a zero-day vulnerability at its root.

Relying on tools or, in fact, any code you've not written yourself makes your system vulnerable. If you understand how an attacker might compromise a system (ref. STRIDE) you can mitigate.

> Relying on tools or, in fact, any code you've not written yourself makes your system vulnerable.

Writing everything yourself, as opposed to widely, community tested open-source alternatives, makes your system vulnerable.

Your example seems to be at the farthest possible end of the spectrum from what I'm talking about.

Not suggesting writing everything yourself. I'm suggesting that the use of third party applications, services, frameworks or components will increase the attack surface. Because you've not written that code yourself, there's value in understanding the attack vectors these components etc. present. Knowing those allows you to mitigate threats.

Maybe we come from different backgrounds. Using open source code that's been subject to lots of eyes and lots of use, e.g. a framework like Django, reduces the surface area, to me, because of the shared best-interest of fixing security problems. The key is staying up-to-date.

Not that you shouldn't understand the potential vectors against your site, or shouldn't read how to use these tools correctly, but a widely tested and used tool or framework, just like a widely researched crytpo algorithm, is better than one with no other eyes on it.