A good developer hates to see an unhandled error in his or her code. If a user sees an error that tells them what line your code failed at, this is not only a potential security risk but also a major point of embarrassment. Bad developers think itâs totally acceptable.
I have this kind of argument all the time– âWhy donât you put an error handler here in case the calling code (or user) enters some bad data.â I get the same response ever time, âBut, how often will that actually happen.â I have this conversations over and over. The only thing that changes is the person Iâm having the conversation with.
When youâve coded for lots of different companies, you start to learn how common this is. You have a few very dedicated developers who cater for errors I canât ever see happening, but you get a lot who are just winging it and stop coding when their work reaches bare functionality. When you see a news story about how a big site was hacked and all their data compromised, itâs not all that surprising. A site can look very professional on the outside and be very shaky underneath.
I was trying to order some travellerâs cheques from American Express today. You may have heard of the company. Iâm sure they spend top dollar for software developers. Iâm still not sure what I did to get this (I wasnât looking for bugs in their software), but I got a big ugly ColdFusion error message:
The error is a standard IIS-delivered unhandled exception error. I know the lines of code that failed. I can even click on a link to see a stack trace. So, you know, I guess itâs embarrassing for the developer (or at least I hope so). But the bigger issue is that I canât trust the site any more.
Somehow, I entered a zero where I should have had a value (and the code is trying to divide by zero), but I honestly donât know where it was done.
Do you think Iâm entering my credit card details after this? I mean, what else are they not paying attention to?
Actually, it looks like American Express sent me to another site (with AmEx branding) called FX4You. But still, it reflects badly on American Express.
The ugly truth of software development is that there are loads of standards, but not many of them are adhered to. Testing always goes out the window to fit delivery deadlines. Code reviews are non-existent in most organisations Iâve worked with. The flip-side is that projects loaded with too much bureaucracy frequently fail to see go-live. There is a happy medium and it is difficult to find.
Back in 2000, when everyone was going crazy about e-Commerce, I was working for a small company looking to build an online shop. One day, I mentioned that I did not trust most websites with my credit card details, someone started to poke fun at me– âIsnât it ridiculous that our web developer doesnât trust buying things on online?â But, even then, I knew how easy it was to leave security holes open in software. Just because I took precautions in my code, I knew not everyone else did. Now itâs almost ten years later and I think most people are more wise to security, but I still would take a site that uses Paypal over a custom-built credit card engine any day.
Maybe I can buy my travellerâs cheques through the American Express site safely, but I wonât risk it.
