3 ms·

Is that really a concern, though? People ignoring warnings like the one at the bottom of the post are probably going to write insecure code anyway. From a purel

by ZoFreX 16y ago

Is that really a concern, though? People ignoring warnings like the one at the bottom of the post are probably going to write insecure code anyway. From a purely selfish standpoint, there is no advantage to me from not posting insecure code examples. In fact, the more people copy-paste such bad code and make sites that get hacked, the more opportunities I have for work when they get fired.

jacquesm 16y ago
That really is pretty selfish. I'm thinking there are two sides to this, the first is that just like you added the 'don't use this' as an after thought the majority of the people that find your code will cut and paste it without actually reading the article, the second is that if this is your 'first approach' to keep it readable you probably have at least a few instances where you forgot to update to more solid code at a later stage because you thought 'x' or 'y' is not facing the web at the moment. And then one day someone bridges two systems and bang, security hole.
- ZoFreX 16y ago
  I know it's selfish, I just thought it was a direction of thought worth exploring. Personally I wouldn't post insecure code without a lot more warnings, closer to (or commented in) the code itself. At the same time I would have absolutely no sympathy for a "programmer" that would copy paste code without even reading the entire blog post it's from, let alone make an effort to understand it. They don't deserve their job. Your point on 'first approach' security holes accidentally being persisted is a good one, and I can certainly think of a few bits of code I wrote that were never meant to be secure, but could potentially be used in a larger, web-facing project at some point. Some food for thought there on perhaps never writing insecure code, even if it's just a test. Tangential addendum: If security is Done Right, then there shouldn't be a choice between "easy to write, read and follow" and "secure".

by ZoFreX 16y ago

jacquesm 16y ago

That really is pretty selfish. I'm thinking there are two sides to this, the first is that just like you added the 'don't use this' as an after thought the majority of the people that find your code will cut and paste it without actually reading the article, the second is that if this is your 'first approach' to keep it readable you probably have at least a few instances where you forgot to update to more solid code at a later stage because you thought 'x' or 'y' is not facing the web at the moment. And then one day someone bridges two systems and bang, security hole.

ZoFreX 16y ago
I know it's selfish, I just thought it was a direction of thought worth exploring. Personally I wouldn't post insecure code without a lot more warnings, closer to (or commented in) the code itself. At the same time I would have absolutely no sympathy for a "programmer" that would copy paste code without even reading the entire blog post it's from, let alone make an effort to understand it. They don't deserve their job. Your point on 'first approach' security holes accidentally being persisted is a good one, and I can certainly think of a few bits of code I wrote that were never meant to be secure, but could potentially be used in a larger, web-facing project at some point. Some food for thought there on perhaps never writing insecure code, even if it's just a test. Tangential addendum: If security is Done Right, then there shouldn't be a choice between "easy to write, read and follow" and "secure".