I still dabble occassionally with programming in my spare time when I get the opportunity. I enjoy writing code but I don’t profess to be particularly good at it – I could make things work but I would take all the short cuts that usually form a good part of the software security presentations that I give thse days and write about. An example I recall with no small amount of embarrassment was in my days leading the development of website a number of years ago. A frantic call from the QA team alerted me to the fact that all of a sudden, whenever anyone tried to log in, the full database connection string was being displayed in the browser – IP address, username, password, the works.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
I launched an immediate investigation and began tracing through the history in the Source Safe database (Microsoft Source Safe is software used for managing project code). The location where the guilty code was contained was quickly found, but who was to blame? Yes, yours truly had left some debug code behind. It was my fault. And that leads me neatly to this great blog from Jeff Atwood entitled “The First Rule of Programming: It’s Always Your Fault.”
Statistically, you understand, it is incredibly rare for any bugs or errors in your software not to be your fault.
Programmers have a tendency to become very defensive about their work. Recently, when being asked to discuss how his code was working, a programmer in one team I’m familiar with retorted to a project manager “I’m here to write the code not justify it.” That’s the same sort of attitude that makes exclamations such as “there’s no risk” and “it’s never been hacked before.” But the point that Jeff makes is one I wish programmers everywhere would take to heart: “If you truly aspire to being a humble programmer, you should have no qualms about saying hey, this is my fault– and I’ll get to the bottom of it.”
These days I live by two rules: 1) Never assume anything 2) If you don’t check then it hasn’t been done.
As ever, for any and all decent guidance on developing secure software I recommend the OWASP web site.