Securing web applications is not a 5 minute job but it also isn't rocket science. Below is a list of various ways in which you can secure your web applications from embarrassing data leaks or hacks. These are not in any particular order.


  • Use checklists so that you don't forget to do things. For instance, I have a checklist for provisioning a new server so I don't forget to do things like tweak the firewall or move a port number.
  • Use a modern operating system for your server. New flavours of Windows and Linux are much more secure than older versions out-of-the-box.
  • Understand, use and configure your firewall. This is one of the easiest ways to harden your server. If you are only a web server, close all ports except 80/443 (and whatever port you use for remote access)
  • Do not use standard ports for remote access. SSH and Remote Desktop can both be used on alternative ports. Simply moving ssh from 22 or RDP from 3389 can stop many people bothering trying to break in.
  • If you use ssh to remotely log in, disable root access and use public keys instead of passwords.
  • If you use RDP, ensure you are using the latest version and enable encryption.
  • Examine logs periodically to detect any attacks. Some attacks occur over many months so you don't have to read the logs every 5 minutes!
  • Do not give everyone in your company access to all your systems - many leaks occur because an unprivileged/un-trained user is fooled into accessing private data.
  • Never use a super admin account to connect your web app to your database. It is nice to know that even if someone were to hack your application, they still couldn't drop a table or select * from users!
  • If you have an admin interface to your system, keep it completely separate from the public web site. Separate application, separate web server, separate connection string, private network access only, full logging for any changes.
  • Keep your servers segregated and simple - the more complexity, the harder it is to manage and the harder it is to know you have secured a system properly. Also, a port opened for one service can be a backdoor into another if you are not careful.
  • Do not trust any input from your web application that comes from the user. Check it all - even in cases where input might be quite free-format, you can restrict the maximum length and check for a few really weird characters. If you really must take all the information, store it escaped in the database so it cannot be used to run code against your system. Have a framework that encourages this and makes it easy for your developers to get right.
  • Have a plan for when things go wrong. How quickly can you disable the system, reset passwords, inform your users etc?
  • Do not invent security. There are so many good libraries available that you will only do it badly. Do not invent hashing algorithms or insist on unusual password policies, "because you think it is better".
  • Do not use default usernames and passwords. In some cases, like Wordpress, admin is a default username so an attacker only has to try and brute-force a password. Changing admin to something else thwarts these kinds of attacks.
  • If your only security is obscurity, you will probably eventually come unstuck but having obscurity as well as security can be good to avoid giving attackers any useful information. Be careful not to advertise everything about your system security unless you have assessed the risk of doing so.
  • If at all possible, use SSL on your entire site and redirect all pages to ssl. Then enable strict http security on your web server and kiss goodbye to 99.9% of man-in-the-middle attacks.
  • Never, ever, ever, ever store passwords in plain text. In fact, consider hashing or encrypting other data like email addresses or street addresses too. A cracked password is mostly only useful with a matching email address.
  • Use the best-practice password techniques such as salted hashes using a strong hash algorithm like SHA512 or bcrypt. Modern brute-force machines can attempt billions of guesses a second! Also, consider blacklisting the dumbest 20 passwords such as "password123" but be wary of password policies that generally force people into using predictable passwords such as Canterbury1986. A general strength meter is better.
  • Be agile enough to be able to address security issues very quickly. If your software is 30 years old and would take 2 months to fix, you aren't going to make many friends if something happens. You also don't want to switch a system off as the only way of disabling the security vulnerability.
  • Things change so often, spend time researching new attack vectors, keep systems up to date, be open-minded with people whose opinions are different than yours.
  • Educate your users in a way that is not preaching. Security has become such a big issue but most users of systems have almost no idea of how web security works.