[jamessocol]

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.

[Spearchucker]

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.

[jamessocol]

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

[Spearchucker]

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.

[jamessocol]

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.