There are an infinite number of ways we can unwittingly introduce vulnerabilities into a website. But one in particular is fairly common and really easy to do if you're not careful.

As a result, I thought we would go over the steps most people use to deploy a new website in order to get their online business, blog or forum up and running for public consumption. This could also apply to anyone who is uploading any new software or content to their website - perhaps you've just undertaken some upgrades which need to be FTP'd over to the live server?

1) Ensure that your website is fully tested and operational - browse it in a number of different browsers at various pages sizes, ensure that the pages can be accessed properly even over slower connections, all hyperlinks should work, test for access to restricted areas, and so on. There's more you can do, but you get the picture...

2) Prepare and package the website for transfer. This may sound a bit silly at first, but remember that new websites often have large amounts of cached data built up. You probably have no need to transfer this across as it just adds mounds of data recorded during website development. It's also likely that there are loose pages, images or scripts hanging around that aren't necessary and removing these is important as it reduces the risk of introducing vulnerabilities.

3) Make sure the live server is ready. You'll most likely need a database, enough files system space, access to an FTP account in order to transfer the files. You also need to ensure that the domain information is correct so that people can browse to the new site without having to type in the IP address.

4) Transfer the files. With a nice clean zipped website ready to go, you can connect to the server FTP and transfer everything across. Once the files are safely on the live host, it's a matter of following procedure to get everything running - extract the files, create and populate the database, configure the database settings (you didn't transfer any usernames and passwords in plain text, right?), and so on.

After testing to ensure everything works properly you can sit back and have a nice cup of tea, content in the knowledge of a job well done. Only there's a real problem. It's a problem that may or may not even show itself for months or possibly years, but it's there...

Can you tell what we did wrong in the steps above? It's such a silly little thing, but the consequences can not only prevent your site from working but damage your business and reputation at the same time:

You might be wondering who in their right mind would be sniffing around a brand new website that hasn't had time to build up large amounts of customer records or other valuable information. The answer is that there is value (for virus creators) in integrating subtly with websites so that they can cause damage over the long term by advertising porn or gambling in encoded white characters that aren't seen by humans but are picked up by search engines like Google, and worse, setting .htaccess directives to redirect users to malicious websites before they have even opened a page on your site.

In this particular instance I am talking about the Gumblar virus that affects PHP based sites. It infected a vast number of websites in 2009. Often, website administrators only discovered that their website had been hacked because they notice traffic coming from porn searches in their analytics accounts. Without that vital clue the virus could have happily redirected traffic to sites that install malware and other malicious code and readers would associate the danger with the hacked site (in other words, your precious new startup) and never visit again because they don't know they have automatically been redirected to another site.

So how does one avoid this problem? Simple; if you have already used FTP to transfer files across to a live server then make sure you change the passwords straight away. In future: