How to secure a Drupal website

OK - I'll hold my hands up. The title of this post is misleading. I'm not going to give you an ABC on how to secure a Drupal site (maybe another day). I'm responding to a post on the Reseller Club blog entitled How to Secure Your Client's Drupal Website.

There is some good advice in that article, but it's mixed in with some bad advice, and in other parts it's just plain confused. In the hope that it helps people, I'm going to try and untangle things.

[Edit: After I posted this, they took the blogpost offline for a while. It's now back (March 2017), and reads quite differently. ;-) ]

Supported Versions

The current Drupal major release is Drupal 8 (8.2, to be exact). Drupal 7 is the major version before that; there are far more sites still running Drupal 7 than Drupal 8, although Drupal 8 adoption is building nicely.

Both Drupal 7 and Drupal 8 are fully supported by the Drupal Security Team. Bug-fixing releases are issued from time to time. Any security-related issues are handled according to the carefully thought through disclosure and release process.

Drupal 6 and earlier are not supported (although there are a few private companies backporting security fixes from later versions back into version 6.)

Let's take the Reseller Club blog post, section by section

1. Make Sure your Login is Secure

They suggest installing three modules: Login Security, Flood Control and Password Policy.

I've not used any of those modules, but they all look like they're worth giving a go. Login Security appears to be actively maintained, with the last commit on 17th October 2016, and with Drupal 7 and 8 releases. Flood Control is currently only in Drupal 7, and hasn't been changed for a while. That need not be a problem, it's maintained by Dave Reid, an experienced Drupal developer, and the lack of changes probably just indicate stability. 13,600 sites currently use it. I wouldn't recommend installing both of those, however. At a guess, they might conflict, or just duplicate functionality that means your site slows down a fraction for little gain.

Password Policy does something different; it is stable for Drupal 7; there is an alpha for you to test on Drupal 8, but it's not production ready.

2. Stay Updated

Yes. Please do that. In Drupal 7, enable the core "Update Manager" module. If you keep a staging site and a live site separately, you could keep this disabled on your live site, but run it on your staging site. Then go to Admin > Reports > Available Updates > Settings. Make sure that you're checking daily (key security issues can be exploited within hours of public announcement). It's up to you whether you get notified only for security releases or for all releases - but I'd advise "all".

I'd also advice checking the box "Check for updates of disabled and uninstalled modules and theme". You may not realise it, but some exploits do not require you to have a module enabled for it to be vulnerable.

Here, the ResellerClub blog post is just a bit confused. It tells you to "Get the [Update Manager] module". There's no need to get it at all. It's been in core since the release of Drupal 7. The page they send you to to get the module is actually a documentation link which currently redirects to the Drupal 8 specific version of that. If you're looking for the Drupal 7 documentation, it's here.

3. Tighten Security Across your Pages

The suggestion is to install the Paranoia module. This could be a sound recommendation, depending on how you use it.

The module does two things. Firstly, it stops you using PHP code in a site. There is an easier way to do that - simply disable the PHP filter. Once you've done that, I can't see why you'd need Paranoia to do this for you.

The oher thing the module does is prevent you granting users to have what it deems to be "risky" permissions. It's one of those modules that may well be worth running while you're in development. But once you've worked out who's going to have which permissions, and you're ready for your site to go live, you don't need the module on your live site. Nobody should be granting roles new permissions on a live site.

4. Use HTTPS to secure your links

Yes. These days, https is fast becoming the new standard, sped along by the likes of Let's Encrypt, of which I'm a huge fan.

However, Reseller Club then advise you to install two modules.

The first is Secure Pages Hijack Prevention. I've no idea why they recommend this. The functionality provided by the module has been in Drupal core since Drupal 7, so there isn't even a release you could install if you wanted to. It is no longer a module that you need or could install on any Drupal 7 or 8 site. That's bad advice, that would just confuse a reader if they tried to follow it.

The other is Security Kit. This is one of those modules I've never come across, and makes me grateful for their blog post for introducing me to it. Sometime, I must have a look at it and see if it's one to use. Do you use it - leave a comment below?

5. Conduct Regular Site Wide Audits

They suggest two modules to do this.

First, Security Review. This does all kind of useful things. I'd recommend installing this on a development copy of your site so you can scan for some of hte common insecure practices that it's designed to detect. You could run it on a live site, but I'd say best not to.

Second, Coder. From the module page:

Coder is not a module, it is used as command line tool and in IDEs.

So they are advising installing a module that isn't even a module. It picks up all kinds of things - missing documentation in PHP functions, inconsistent variable naming or indentation conventions, and so on. These are all only relevant for modules that you have coded yourself, or if you're patching an issue and want to check that your patch won't introduce any problems at this level. It won't help your site security. But do use it if your write your own custom modules, or if you contribute to Drupal's contrib repository.

6. Use Two Factor Authentication

Yes, yes and yes.

Any site that lets users log in should offer them some form of 2FA. Drupal has a module that does this for you, which is stable for Drupal 7. This is especially important for any e-commerce site, or any other site where users may submit sensitive information.

Others?

So their blog post includes some cracking good recommendations. It also recommends installing a module that isn't actually a module, a modules whose functionality is in core and so no longer exists, and another module that should never be run on a production site.

My fear is that people will follow some bad advice. My other fear is that people will be confused by the misleading advice. Both those fears arise because I don't want people to miss the chance to follow the good advice that is there, put off by the other bits and pieces that don't quite seem to work.

If you're reading this, the chances are you have your own security tips and tricks. Pile into the comments section with your thoughts.

Hosting

There's a lot of discussion about how to host a Drupal website. I've reviewed the VPS providers that I've used and can recommend HERE. There are plenty I've used and wouldn't recommend - they don't get a mention!