Website Security: What You Need to Know as a Site Owner

Hacked sites. Security flaws. Lost data. Loss of trust. Lost customers. Lost revenue. Nightmare.

Just thinking about themes such as these in the media can send a shiver down your spine. It can all seem very daunting, and not just a bit scary when you start to think about it. This article aims to paint a clear picture of what you should be aware of as a site owner - where security weak points are, and strategies to avoid them.

My Website Has a Password - That Makes it Secure, Right?

Security, like the technology behind a modern website, has many facets and layers. Alas, merely password protecting your site admin screens is not enough. Having said that, I do remember, in the bad old days, being presented with a site without even that, such that anyone who guessed the admin URL could edit all the site content.

Unlike back then, security is now a serious business and needs to be treated as such.

Starting from the first point of contact and working down, the security layers are:

• Password protected user accounts
• Appropriately set permissions for user accounts
• Protected forms
• Secure file location
• Securely written site code
• Up to date site code
• Up to date server applications
• Up to date server operating system
• A secure location for your server
• Encryption for traffic to and from your site

User Accounts

It may seem obvious that a strong password is important, but alas, people don't seem to take this very seriously, as evidenced by this article from TechCrunch.

Fortunately, there are Drupal modules to help avoid chronic passwords, e.g. Password Policy and Password Strength to name but two.

A password is only half the battle, though. Drupal ships with a powerful and fine-grained permissions system that allows a site administrator to dictate what users can and cannot do. It is critical that proper attention be paid to user permissions when setting up a site or introducing new features.

Protected Forms

Following on from user account permissions, forms, e.g. content editing forms, comment forms, contact forms, should all be viewed as potential areas of attack and need to be locked down. The safest thing to do is simply restrict who has access to a form. E.g. only site editors can post new content. But in the event that other users can use forms, strategies to limit the potential for harm include: using a text filter on text inputs so that no potentially harmful tags, such as