One of the nice things about Drupal is the low barrier to entry: anyone can download it, install it & have a basic site up and running in a few minutes. Unfortunately, once the initial setup is complete, people often don’t bother to look at anything else other than what they need to start adding content to their sites.

When the site gets “hacked” or overrun by spam bots, they up frustrated and either blame Drupal & move on to something else or end up seeking out (and paying for) professional help to clean up something that they could have easily prevented. Below are a couple simple, common sense measures that anyone can take to avoid some common pitfalls.

Figure out who really needs an account

If only a couple people will be adding or changing things on the site, then they are probably the only ones who should have accounts on the site. In that case, you should disable user registration and add the accounts manually (or at least set it to require admin approval for registrations).

If there is a need for members of the general public to have accounts, you will need to prevent automated registrations. Requiring email validation is a good start and should always be enabled if you are letting people register but it is not effective on it’s own. To help prevent automated registrations, you should install a module such as CAPTCHA, Mollom, or Are You a Human (that last one is our favorite here at Commercial Progression).

Check your permissions

This is an important step that is often neglected. Think about who will be using your site and what they will be doing. Especially on simple sites that aren’t using custom roles, people often leave the default permissions. Unfortunately, these defaults may not make sense for the situation. Here are a few general guidelines to consider:

  1. Anonymous users typically don’t need to do anything besides view the site.

  2. Think carefully about the special “Authenticated User” role. If you aren’t restricting registration, adding permissions will grant them to anyone who registers. Even if you are restricting registrations, it’s still a good idea to create a separate role with any special permissions and explicitly assign it.

Seriously? That’s it?

First, this is not meant to be a comprehensive guide. It’s meant to address a few easily avoided issues. Some more experienced people may also think that nobody would make these mistakes and that most of what is presented here is common sense. I don’t deny the common sense part, just look at the title of this post. As for nobody making these mistakes, everything mentioned here is based on something that I have seen at some point.