Keeping a regular, static website secure is a relatively easy task. As long as you pay attention to maintaining all your server software with regular updates, and you follow some standard security practices, you should be fine. However, things are much different when it comes to a dynamic site – that is, one that has content which changes on a regular basis.
When you’re running scripting languages, databases and other similar entities, you’re opening up all sorts of potential backdoors that malicious users can exploit to gain access to your site. What they can do from there depends mostly on the type of service you’re running, but keep in mind that it’s not rare for attackers to exploit vulnerabilities in one site to gain access to another hosted on the same system or network. Sure, most hosting firms, even cheap web hosting companies will offer some form of protection, the book unfortunately stops with you, so you really need to do your upmost to protect your site and your server from the ground up.
Writing your own scripts? Always sanitize user input!
A common attack vector for dynamic sites relies on a method called “SQL injection”, which exploits improperly written routines that are supposed to verify user input. A carefully crafted request to your site can produce unexpected results, including, but not limited to, having your entire database dumped, deleted tables, users gaining access where they shouldn’t, and more.
SQL injections are old news nowadays, and most Web scripting languages have some built-in mechanism to prevent them from occurring. “Prepared statements” are a good example of that, and it’s a feature found in many modern languages that can save you a lot of trouble.
As a rule of thumb, don’t try to do the sanitization yourself, as you’re very likely to miss something important. What’s more, you probably won’t be aware of all current security trends that you need to observe, resulting in an implementation that’s just waiting for someone to exploit it. In fact, DIY approaches to site security are generally frowned upon, and for a good reason.
Keep your tools and applications in check
We mentioned this above with regards to static sites, but it’s just as important for dynamic ones as well – you will want to always make sure that you’re running the latest version of things like Apache, PHP, MySQL (or your corresponding alternatives). This also applies to any Web applications you might be running on the server as well, such as WordPress, phpBB, Joomla and more.
There are some tools that can significantly simplify this part of your work and help you stay up to date with relatively little effort, maintaining the status of all your applications for you. Of course, even these tools are not a magic wand solution, and you should put in some manual work to ensure that you’re covering all your bases properly.
It’s not a bad idea to pay a visit to some online security communities and subscribe to their discussions. Even if you don’t understand a large part of what’s being said, you should at least catch the occasional glimpse into new releases of security suites, exploits, and other details that might be of interest to you. Stay one step ahead and always know what’s out there that can be used against you!
Storing sensitive data separately
If an attacker does manage to compromise your security though, this doesn’t mean that they should be able to obtain all your vital information and potentially use it against you. It’s a good idea to store things like long-term backups off-site, along with any other data that you don’t need to have available immediately. There are various ways to compartmentalize your website to make it as secure as possible against intruders, and you don’t necessarily have to hand all your data on a silver platter when someone does manage to break in.
Of course, this is not applicable to every site out there, and the way some systems work will prevent you from utilizing such a design. But as long as it applies to you in at least some capacity, you should be able to make any potential attacks far less dangerous.
On the other hand, some data will be impossible to store like this – such as the current copy of the databases you’re working with. In those cases, see if you can possibly split the data itself into different segments according to their relevance. For example, you could archive some part of your site and have it available with delayed access, while only keeping the most important things immediately ready for users.
This doesn’t always work, and it can severely degrade the user experience with some types of sites, so you should think carefully about whether or not it’s an appropriate solution in your case. When in doubt, consult your database architect and see if they can shed some light on your current data storage practices and how they can be optimized. Chances are, they might already have something on their mind if they’re more experienced in their field.
