1. Attacks on the underlying server and its software
2. Attacks on the website application container (runtime level - ASP, PHP, etc)
3. Attacks on the website database (MySQL, MS SQL Server, Oracle, etc)
4. Attacks on weaknesses in the website code itself
5. Social engineering attacks

Techies may look at points 1 and 2 and think that they are largely the same issue but I think there is a subtle distinction between an attack on the server software (like say Linux/Apache) and an attack which exploits a problem with PHP or ASP for example.

Server level security

As a web developer, there is very little you can do about points 1 and 2 except pick the most suitable server technology and development technology for the level of security you want to attain. Banks for example tend to use Java (JSP/Servlets) on something like Sun's Solaris operating system because used correctly its a very, very secure software stack and they can afford to add loads of hardware to boost performance. Of course many web developers are not used to writing web apps in Java and performance wise its not great so if you don't need bank-vault levels of security, there are other more suitable options

The more popular of these options at present tend to be PHP, Microsoft's ASP (both classic and the newer .Net framework) and Ruby on Rails which is increasingly gaining traction. They all take security seriously at an application level although they don't prevent the programmer from making stupid mistakes.

Increasingly, the key at this level is to make sure you're running the latest production version of the software, this will be the most patched version and will have the least security holes. Running older versions may leave your server vulnerable to automated scanning bots which are designed to exploit specific security holes automatically.

In general, the trick here to to make sure you've got a really good sysadmin who is suitably paranoid and knows what they are doing. This is an area of expertise in itself and sysadmins are paid good money to be on the ball. Its really too much to expect a web developer to be a good developer and a knowledgeable sysadmin, there is just too much to know.

Securing the Database

A website of any great complexity will usually have a database behind it to help store and organise content. Sometimes this database will contain some personal information of the regular users of the site, think "My Account" functionality in a e-commerce store, or even something as simple as a newsletter sign up form. Hackers (technically called Crackers or black hats in the industry) will try to gain access to the database either directly or through the website code.

Many hosting companies prevent direct access to the database by putting it behind a firewall or stopping it from accepting an connections from anywhere other than the machine its actually running on (local connections only). This is good from a security standpoint but a pain in the behind for developers who often don't have direct physical access to the server.

A good middle road is to provide an encrypted connection to the server via something like a Virtual Private Network (VPN) and allow the database to accept connections through that. A lot of custom setup is involved in something like this though and it could get quite expensive if you don't have your own dedicated server and a good working relationship with the administrator of the network it sits on!

If you absolutely need access to the database server from a remote location and a VPN is no good then you have to allow the database server to accept remote connections. Here you can use a firewall to limit the IP or MAC addresses of the remote connections. You will also need to limit the power of the user accounts that can access the database. If you don't need the ability to drop tables or delete rows, then disable it. Keep the root password safe and never, ever, use it. Always create user accounts of limited power for specific tasks, that way if anyone ever cracks one of the user accounts they wont have all the keys to the kingdom.

Keeping your data encrypted within the database tables is also a good call here. That way if the cracker ever gains direct access to those tables, they still have the task to decrypting the data before they've got anything useful. You could even go as far as using different encryption keys for different tables or using multiple encryption passes on the same data using different routines although thats a little extreme.

Part 1 Conclusion

As a web developer the platform choices you make can have a direct effect on how secure your site is, but in practice the choices and differences between platforms are relatively few unless you need extreme security. Securing the underlying database is at least as important as making sure your website code is secure. Forward planning and common sense here can make a hackers life much more difficult.

In the next part I'll talk about how the website code itself can be attacked and techniques that can be used to prevent a successful attack and limit damage.