Every application or website exposed to the internet is susceptible to be exploited by malicious users. Here are some of our team's best practices and essential modules to secure any new Drupal installation.

Jump to checklist download

In this article:

Password Policy

The Password Policy module allows developers to configure some politics to make the passwords more secure. It’s recommended to install it to force users to change the passwords frequently and to use secure passwords.

We recommend setting the following policies:

  • Password username: username should not be part of the password.
  • Password history: last X passwords can’t be repeated.
  • Character types: use at least X character types.
  • Password length: password should be at least X characters long.
  • (Optional) Password strength: the Password Strength module allows to require at least some level of strength for the password based on some predefined metrics.

Also, password expiration time could be added into the mix if the client thinks it’s needed. However, it’s good to note that some prominent figures in cybersecurity are starting to speak against frequent password expiration policies. They argue that sometimes, these policies do more harm than good. You can read a bit more about this in the following links:

Two Factor Authentication

The Two-factor Authentication (TFA) module permits the use (and force) of a second factor to login to your Drupal site. It’s always recommended to rely on something that you know and something that you have to secure the authentication for a site or application.

Redirection to HTTPS

Ensure that if someone enters a HTTP address, it will be redirected to HTTPS. This will make communications more secure and avoid cases where you’re logged in to HTTP but not HTTP or the other way around.

This redirect can be done in different ways depending on your site and hosting platform.

Acquia

Acquia supports .htaccess so redirect should happen in this file with some code like this:

  # Exclude acquia-sites.com domains.
  RewriteCond %{HTTP_HOST} !\.acquia-sites\.com [NC]
  RewriteCond %{HTTPS} off
  RewriteCond %{HTTP:X-Forwarded-Proto} !https
  # Redirect with HTTPS.
  RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Pantheon

If the site is hosted on Pantheon and there’s only one domain, you should choose the primary domain in the dashboard and redirect via hsts will happen by default.

If the site is hosted on Pantheon and you have multiple domain, you should code your redirects in the settings.php like this:

// Redirect to https in the same domain. 
if (isset($_SERVER['PANTHEON_ENVIRONMENT']) && ($_SERVER['HTTPS'] === 'OFF') && (php_sapi_name() != "cli")) { 
 if (!isset($_SERVER['HTTP_USER_AGENT_HTTPS']) || (isset($_SERVER['HTTP_USER_AGENT_HTTPS']) && $_SERVER['HTTP_USER_AGENT_HTTPS'] != 'ON')) { 
 header('HTTP/1.0 301 Moved Permanently'); 
 header('Location: https://'. $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']); 
 exit(); 
 } 

}

Security Kit Module

The Security Kit module allows you to harden some security settings for your Drupal site by configuring some security related headers to send to the browsers. It’s recommended to install and configure this module. It’s recommended to tweak at least the Content Security Policy, Clickjacking and Feature Policy settings.

Content Security Policy

In this section, you should enable sending the header (“Send HTTP response header”) and optionally (but recommended) “Enable Upgrade Insecure Requests”.

It’s recommended to set this up at the beginning of the project to be able to tweak the trusted sources if something fails. You could also set this section to “Report Only,” but if you do this you should keep an eye on the logs and later switch it to default mode after doing the needed adjustments.

Clickjacking

In this section, the X-Frame-Options should be set to only allow attempts of framing from the same domain (SAMEORIGIN).

If it’s ok for your site to work ONLY with Javascript enabled, you could also check “Enable JavaScript + CSS + Noscript protection” to add additional prevention measures.

SSL/TLS

In this section you could configure HSTS header. Keep in mind that if the site is hosted in Pantheon, you should instead use Pantheon settings for HSTS: https://pantheon.io/docs/redirects#set-hsts-with-pantheonyml. Please read carefully the available documentation about HSTS before enabling it in your site because if SSL is not well configured, you may lose access to the site.

Feature Policy

This section allows you to selectively enable/disable some APIs and features available in the browser. You can see Google's developer documentation for more information on this.

Depending on your site, you could enable/disable geolocation, camera, microphone and other features. When you do this, if an iframe (or other object) tries to use those features it won’t get access to them so, you should be careful when you set this up. If you enable the policy, you need to specify the policy you are going to use.

An example policy that could be used as starting point for sites that use (or could use) geolocation but will never use camera and microphone is:

geolocation 'self'; camera 'none'; microphone 'none';

You should check all of the other available options for seckit module and tweak them as needed for your site.

Role delegation module

By default in Drupal, if you have the “administer users” permission, you’re able to grant any role to any user. Otherwise, you can't grant roles.

The Role Delegation module allows a more granular control over roles so that you can configure which roles should be able to grant what roles. This way, a “Super Editor” role could grant the “Editor” but not the “Super Editor” role to another user. If this control is needed in a Drupal site, it’s recommended to enable this module.

Autologout module

The Autologout module allows you to configure a timeout to logout users from your site due to inactivity. It could be set globally or per role and you could grant the users the permission to specify their timeout up to a maximum time specified in the module config.

Rebuild Cache Access module

Sometimes we need to grant the users the ability to clear cache. By default, the only way to do this is to grant some really general permissions which could lead to granting access to other stuff that we don’t want to. The Rebuild Cache Access module adds a button to the administration toolbar controlled by a permission so that you can grant access only to rebuild cache and nothing else.

Get the Checklist

Fill out this form to download a one-page PDF recapping the above tips.

Loading form data...
Category
Drupal and Web Development
Tags
Drupal
Guide
Tutorial