4 ms·

You can also build horribly insecure applications with a framework. A framework does not absolve you from thinking, which seems to be the point the author is ma

You can also build horribly insecure applications with a framework. A framework does not absolve you from thinking, which seems to be the point the author is making. There's a difference between frameworks and libraries and of course it is a good idea to use trusted crypto implementations and avoid NIH syndrome, but a large part of security is including it in the design process from the start. You can't just assume "the framework will handle it", or "bcrypt is all I need" or "the opsec team will find all the problems". It rather sounds like you're expecting the author to hand you a magic-bullet solution, which is rather the whole point of the article: there isn't one. You do need to know what you're doing.

tclancy 10y ago
The jack of all trades is the master of none. Almost no generalist is going to be good enough to properly handle all security concerns. I like knowing my framework is constantly upgrading password handling, XSS attack prevention and things I haven't even heard of yet. The fact you can build insecure things in a framework isn't an argument against it and why would someone who builds a horribly insecure app in a framework produce a better result without using one?
- robert_tweed 10y ago
  They probably wouldn't, but that's neither something I said, nor is it the article's premise. However, a framework does increase the attack surface, which is something that should be taken into account. If you save 20 lines of code by adding a 100,000 line framework, you need to ask yourself which of those is most likely to contain a bug? Plus, bugs in popular frameworks tend to get exploited in practise. Other bugs less so, because of the need to first find the bug. The odds of that happening will increase if the bug is common and obvious, or you are a particularly high-value target. By using a framework you effectively increase your value as a target to the sum value of all projects using that framework. This becomes especially bad if the framework stops being maintained, because the value to an attacker isn't lost as quickly. The above also applies to libraries, but libraries tend to be more focused and more stable than frameworks, since frameworks tend to "go stale" if not continually updated in a way that most libraries do not.
- jsjohnst 10y ago
  Who is to say your framework of choice isn't written by generalists just like the generalist your creating the straw man argument against?
V-2 10y ago
> You can also build horribly insecure applications with a framework "You can also find sober drivers that cause accidents". Of course, but it doesn't invalidate the fact that drinking and driving is a bad combo and puts you and others in greater danger statistically. It's sort of similar here.

tclancy 10y ago

The jack of all trades is the master of none. Almost no generalist is going to be good enough to properly handle all security concerns. I like knowing my framework is constantly upgrading password handling, XSS attack prevention and things I haven't even heard of yet. The fact you can build insecure things in a framework isn't an argument against it and why would someone who builds a horribly insecure app in a framework produce a better result without using one?

robert_tweed 10y ago
They probably wouldn't, but that's neither something I said, nor is it the article's premise. However, a framework does increase the attack surface, which is something that should be taken into account. If you save 20 lines of code by adding a 100,000 line framework, you need to ask yourself which of those is most likely to contain a bug? Plus, bugs in popular frameworks tend to get exploited in practise. Other bugs less so, because of the need to first find the bug. The odds of that happening will increase if the bug is common and obvious, or you are a particularly high-value target. By using a framework you effectively increase your value as a target to the sum value of all projects using that framework. This becomes especially bad if the framework stops being maintained, because the value to an attacker isn't lost as quickly. The above also applies to libraries, but libraries tend to be more focused and more stable than frameworks, since frameworks tend to "go stale" if not continually updated in a way that most libraries do not.
jsjohnst 10y ago
Who is to say your framework of choice isn't written by generalists just like the generalist your creating the straw man argument against?

V-2 10y ago

> You can also build horribly insecure applications with a framework "You can also find sober drivers that cause accidents". Of course, but it doesn't invalidate the fact that drinking and driving is a bad combo and puts you and others in greater danger statistically. It's sort of similar here.