None of the websites I have custom coded from scratch have ever been hacked. I’m not saying I’m the world’s best web developer, I will assume my readership is smart enough to draw that inference for themselves!

On the other hand, several sites that I have worked on that used “off the shelf” type programs for CMS or e-commerce have run into problems of late. It stands to reason that if enough people use and abuse a product they will eventually find flaws and security holes in it. In every case, the security exploits had been known about for quite a while and patches/upgrades available .

So why weren’t things patched? Well, the reasons for not patching up mainly fell into two areas:

1. There was no longer a technical resource available to perform the required actions
2. The site had custom modifications that prevented a straightforward patch/upgrade

Now as a professional web developer I can’t really do much about it if a client doesn’t want to pay me or someone else to keep the site updated and patched. I’m unlikely to be overly pro-active about getting in touch with customers from a few years ago that might need to upgrade when a particular security flaw is uncovered, but I would drop them a mail if I thought it affected them.

I can understand a customer’s reluctance to engage me on an ongoing basis or even to bring me back in every year or so to perform updates. Most of the projects I do are brought to a stage where the site or web application can be managed and operated by non-technical users, the idea being that the customer stumps up a higher up front cost for a system that doesn’t require regular interventions and updates from a techie, thus saving them money in the long run. I think though, for my part I will have to flag the necessity of security updates to clients outside of any other ongoing maintenance/support contracts which they may or may not want.

Most of the off the shelf systems such as Joomla!, Mambo or X-Cart (which I use for some e-commerce projects ) have very easy patch/upgrade systems that would even allow a non-techie with a bit of bravado (and hopefully a database backup!) to perform the update.

This assumes however, that the core code and functions of the website application remain intact, and this is not always the case. The customer might require an extra piece of functionality that is not currently present and must be custom coded. In this case, the preference would be to develop some sort of module or plug in that stands outside of the core code, allowing a clean upgrade path. There is no guarantee your own custom code will still work once the update has been run, but in most cases it should be straightforward enough to do, and at least the main body of code has been updated without much trouble.

In instances where there have been modifications to the core code, the task becomes more complex. The developer then needs to see what the upgrade/patch is changing, and then manually apply the code updates/patches using some sort of text file comparison/merging tool. In short a bit of a nightmare!

There are often very good reasons at the time of development for modification of core code in this manner. It isn’t always possible to code add on functions as separate code or indeed source a program that does everything you want, exactly as you want it to, and if the customer has a genuine requirement for a particular feature, then who am I to argue?

I might not argue, but I should underline the seriousness of breaking the upgrade path to a product. It really adds significant costs to future upgrades which in turn might have the consequence of necessary updates and upgrades being put on the long finger.

It isn’t always the customer though. Sometimes the web developer can be lazy and simply lash something in any old way without worrying too much about how it might affect things in a years time when an upgrade is needed. After all, he or she will have retired to a non-extradition Caribbean island by then. As a developer it is important for me to ensure a clean path to future updates/upgrades for web applications wherever possible.
If your site is running an off the shelf web application, it is important that you make yourself aware of any security updates and alerts that come from the developers of the application. Even if it is just to check that your techie is applying the necessary updates, it is an important step. Ultimately it won’t be the guy who did the site 3 years ago that suffers most if your site is hacked using a year old exploit…