Securing your site

This section provides security configuration advice for site administrators and includes both "things you should actively do" and "things you shouldn't do". The order of chapters is an attempt at identifying the priority of the configuration based upon the likelihood that it will be helpful, and the potential benefit/harm of the configuration.

There is also a page elsewhere on reporting a security issue.

Site administrators should also sign up for the security mailing list. People interested in discussing security should join Best Practices in Security Group.

Enable the Drupal core Update Manager module, and configure it under Reports > Available updates > Update Manager settings, making sure a real email is used, and not a test address.

There are a number of contributed modules which can help with security, not all of which are documented in this handbook. One such is the Security Review module which provides an analysis of your security configuration.

You can also read documentation for writing secure code and about the security implications of translations from localize.drupal.org.

The key to security is eternal vigilance. Updating code, both within Drupal and across your hosting infrastructure, is a necessary process to ensure you stay secure. Setting up a secure Drupal web application server and walking away is not sufficient. Be aware of the update process for your systems (The Drupal Security Team releases Security Updates each Wednesday), and ensure someone is keeping on top of this, with sufficient time allocated to perform updates to Drupal, your web server software, database software, and all other packages installed on your systems.

Security updates can be followed through the Drupal Security page.

RSS feeds are also available for core, contrib, and public service announcements.

You can also follow drupalsecurity on Bluesky or drupalsecurity on Mastodon/Fediverse.

In addition all security announcements are posted to an email list. To subscribe to email: log in, go to your user profile page and subscribe to the security newsletter on the Edit » My newsletters tab.

Check for vulnerabilities with Cron-triggered script

As a supplement to the Update module, you can run the composer audit command regularly via a Cron-triggered script, sending you an email if a vulnerability has been found. The example below assumes Git is used, to find all sites. It watches all dependencies too (not just modules):

#!/bin/bash

# Pull the latest changes and run a Composer audit.
# Exit code meanings:
# - 0: No vulnerabilities found.
# - 1: Vulnerabilities detected.
# - 2: Errors occurred (e.g., missing lock file, configuration issues).
/usr/bin/find /PATH/TO/ALL/YOUR/SITES/ -mindepth 1 -maxdepth 2 -name '.git' -type d -execdir sh -c '
    # Reduce HTTP concurrency to avoid transient Packagist timeouts.
    export COMPOSER_MAX_PARALLEL_HTTP=${COMPOSER_MAX_PARALLEL_HTTP:-2}
    git pull -q
    # Only run in repos that actually use Composer.
    [ -f composer.json ] || exit 0
    audit_output=$(composer audit --locked --no-interaction --no-dev 2>&1)
    result=$?
    case "$result" in
      0) ;; # No vulnerabilities found.
      1)
        echo "$(pwd):"
        echo "$audit_output"
        ;;
      2) ;; # network timeout: skip silently to avoid cron mail
      *)
        echo "$(pwd): unexpected exit code $result"
        echo "$audit_output"
        ;;
    esac
' \;

Kindly shared by @joelpittet in #3553118: False warning about Views Bulk Operations (VBO) security update.

Add this in Crontab to send out an email, if anything produces output, i.e. a vulnerability is found:

MAILTO=security@example.org
PATH=/usr/local/bin:/usr/bin:/home/USER/bin

# Check composer security audit once a day.
35 8 * * * /home/USER/bin/composer_audit

Tips and adjustments

Here are some tips, for easier testing of the script via the command line. You may also need to adjust the script, to accommodate your local environment.

Composer cannot be found

You may need to register the path to where Composer is installed (find with whereis composer), by including it at the top of the Crontab (assuming Composer file is in that folder):

PATH=/home/USER/bin

Relative path is insecure

Setting ./vendor/bin as a global PATH is the recommended method for Drush. This is not a problem in Crontab, but while testing the script from the command line, you may get an error like this:

find: The relative path ./vendor/bin is included in the PATH environment variable, which is insecure in combination with the -execdir action of find.directory

During testing, you can prepend the command with this, to reset PATH and use a custom version:

$ PATH=/usr/bin:/usr/sbin:/home/USER/bin bash bin/composer_audit

Alternatively, set up Drush in vendor/bin with relative path, by adding this in a dot file (zsh profile, or .bashrc):

# https://github.com/drush-ops/drush-launcher/issues/105
function drush () {
  $(git rev-parse --show-toplevel)/vendor/bin/drush "$@"
}

Path and maxdepth

If your web sites are in the structure /var/www/example.org/public_html, use /var/www and -maxdepth 3, to accommodate the deeper paths.

Add extra, formatted email

To add an extra formatted email, add this under 1) in the script:

      1)
        echo "$(pwd):"
        echo "$audit_output"
        {
          echo From: info@example.org
          echo To: info@example.org
          echo Subject: Security update for $(pwd)
          echo
          echo "A security vulnerability has been found in $(pwd): \n\n $audit_output"
        } | /usr/sbin/sendmail -t
        ;;
      2) ;; # network timeout: skip silently to avoid cron mail