5 ways to secure Drupal 10

Drupal is a popular content management system (CMS) that leading corporations and government agencies use for mission-critical applications. With a supportive community of developers, robust security, multilingual support, compliance with WCAG guidelines, and ease of integration, Drupal is a go-to CMS.

Drupal 10, slated to release in December 2022, comes loaded with exciting new features. Notable changes include implementing an automated update system, replacing some jQuery uses with vanilla JavaScript in core, upgrading third-party dependencies (CKEditor 5, Symphony version 6, PHP 8.1), and removing some core modules like HAL, QuickEdit, Aggregator, RDF, and Activity Tracker. These upgrades will improve website performance and provide a strong user experience.

While the transition from Drupal 9 to Drupal 10 is expected to be as smooth as the move from versions 8 to 9, we can’t afford to let our guard down regarding security. After all, our Drupal 10 CMS can still be subjected to attacks by malicious actors. So, in this article, we’ll explore five security best practices for Drupal 10.

1. Keep an eye on vulnerabilities

One of the most important things we can do to protect our Drupal site is to track known vulnerabilities for Drupal through the Snyk Vulnerability Database and remain up to date on the latest Drupal security advisories to stay ahead of potential vulnerabilities. There are several ways we can do this:

• The security team at Drupal posts security advisories every week. To stay on top of security news, sign in and subscribe to their email newsletter, join the Drupal Slack group, or follow RSS feeds.

• Drupal has a built-in Events Logger viewer that we can use to monitor our sites and spot suspicious activities regularly.

• The update manager, part of the Drupal API, regularly checks for new updates and informs us about them. You can configure it by adding your email address in the Manage administrative menu to receive the latest security updates.

• You can use Drush to automate time-consuming tasks and quickly apply security updates. For example, if we want to implement a security update in the Drupal UI, we’ll have to log in, find the module, import config changes, and more. With Drush, we can perform the same action with a single command, making it easier to complete security updates routinely.

2. Understand cross-site scripting attacks (XSS)

As per the Snyk Vulnerability Database, there are few vulnerabilities in Drupal. However, of the reported vulnerabilities over a 20-year period, a large percentage are cross-scripting (XSS) attacks. XSS is a JavaScript vulnerability where threat actors inject malicious code via JavaScript or HTML into client-side scripts.

Unaware of the danger, web application users are tricked into executing malicious code. Once executed by the user’s browser, attackers can steal our session tokens and impersonate us to perform actions only we should be able to do — including gaining access to private systems.

There are three XSS attacks: reflected, stored, and DOM-based.

Reflected (non-persistent) XSS

Reflected XSS is the most straightforward XSS attack, where the XSS payload is reflected off a web application to a user’s browser. Since this attack is non-persistent, the payload isn’t stored on the website. Instead, the script gets embedded at the end of a URL. When the user clicks on it, the malicious payload is initiated.

Stored (persistent) XSS

The stored attack is the most dangerous attack on client-side servers. It happens when the bad actor injects the payload into the targeted database. If there’s no data validation, it gets stored permanently on the website. When users open the affected web page, they inadvertently execute the payload in their browser.

DOM-based XSS

A Document Object Module (DOM) attack is a client-side attack where the attack payload isn’t sent to the server. These attacks are difficult to detect because they don’t appear in server logs.

Let’s see how an XSS attack takes place.

Consider an ecommerce website for sporting goods. It has a search function that receives the user-entered data in a URL parameter, like this:

1https://notsecured-website.com/search?term=tennisracquet

The above application gives details of the tennis racquet searched for:

1<p>You searched for: tennisracquet</p>

As we can see, there’s no input validation. As a result, it becomes easy for hackers to change the URL and insert malicious scripts, like so:

1https://notsecured-website.com/search?term=<script>/*+malicious script+*/</script>

When a user requests the hacker’s URL, the malicious script gets executed in the user’s browser, and it results in the following response:

1<p>You searched for: <script>/*+malicious script+*/</script></p>

To effectively prevent XSS attacks, we need to:

• Implement a Content Security Policy (CSP) to detect and neutralize XSS attacks.

• Use frameworks that escape HTML tags.

• Invest in a log management system that logs everything.

• Follow OWASP security best practices.

• Convert HTML control characters into context-sensitive encoding.

• Never allow raw HTML coming from input users to be rendered.

• Regularly scan our databases with web vulnerability scanners.

3. Always use HTTPS

Bad actors can exploit vulnerabilities in your HTTP Drupal website to successfully execute pharming, phishing, and man-in-the-middle (MITM) attacks, as the HTTP protocol transmits data in standard text. To secure the connection between the two parties, we should always use HTTPS. To do so, we need an SSL certificate, a secure protocol that encrypts website traffic.

SSL certificates use asymmetric and symmetric cryptography to encrypt communications and make them more secure. So, even if our data gets intercepted, it won’t serve any purpose because the data is in a jumbled form, making it unhelpful to a hacker.

4. Apply the principle of least privilege

It’s not uncommon for organizations to have privileged accounts in use. However, privileged accounts offer more opportunities for malicious actors to exfiltrate systems and cause significant damage. Hence, you should always apply the principle of least privilege (POLP), where you restrict access rights to only those resources your users need to complete their tasks.

Using POLP refers to assigning users the minimum amount of permission required to complete their necessary tasks — and no more. By limiting users’ access to different parts of our Drupal site — and our infrastructure, databases, and resources — we decrease the likelihood of bad actors within and outside our organization accessing things they shouldn’t be. The primary way of implementing POLP is by assigning roles defined by specific permissions.

Users in Drupal are assigned roles that have permission to view and edit content. We can define the permissions in detail on the Permissions page. Setting up permissions in Drupal is easy. First, access the Admin panel, click on the People menu, and then click Permissions to grant users access based on their roles.

Drupal permissions fall under the following categories.

Anonymous user

The anonymous user role applies to all users who are not logged in. Users are typically granted read-only permissions and have the least access.

Authenticated user

Authenticated users are those who are logged in. They typically have more rights than anonymous users and will generally have their identity verified through a username/email and password login system.

Administrator

The administrator — or root user — has root privileges with which they can make extensive changes to the system. You should always be careful when accessing our Drupal website as a root admin, as even a minor error can be disastrous for your website.

RBAC access control

In addition to the permissions outlined above, Drupal uses role-based access control (RBAC). With RBAC, Drupal enforces the POLP and enables us to control what users can see and do on our site. By providing role-based access on a need-to-know basis, we ensure that only trusted personnel have access to our business-critical data.

5. Harden with Drupal security modules

A module is a collection of JavaScript and PHP files, which add new attributes to your Drupal website and increase its functionality. Drupal offers a variety of modules to improve the security of Drupal sites, including the following.

Login Security module

The Login Security module is a vital Drupal module that restricts the number of invalid login attempts. It can also permanently or temporarily block specific IP addresses. Additionally, Drupal administrators can configure the module to notify them whenever there’s a brute-force attack or other undesirable activity.

Security Review

The Security Review module checks our website for minor development errors that could leave it vulnerable to attacks. While the module makes no changes, it runs a security test highlighting the vulnerabilities that bad actors can exploit. Once we get the report, we can review the highlighted portions and harden our site against bad actors.

Security Kit

The Security Kit (SecKit) module has multiple options to identify common web vulnerabilities like clickjacking, cross-site scripting, and cross-site request forgery attacks. It also helps to execute HTTP response headers to prevent MITM attacks.

Password policy module

The password policy module is a contributed module that helps us configure password policies for specific roles. It enables site administrators to define various types of password policies, each with constraints (sub-modules) to meet before changing a password. The constraints include:

• Uppercase

• Lowercase

• Delay

• Letter/Digit (Alphanumeric)

• Length

• Punctuation

• Username

• Digit placement

Two-factor authentication module

Two-factor authentication (2FA) works by adding an extra security layer to our Drupal website, ensuring only users with valid authentication are allowed access. The TFA module provides interfaces where we can select several 2FA solutions like SMS-delivered codes, time-based one-time passwords, or pre-generated codes.

Keep your Drupal CMS secure

With 1 in 30 websites running on it, Drupal is a popular, trustworthy solution for our websites. So, what makes Drupal so secure?

Drupal adheres to OWASP security standards, has robust and granular access controls, and offers a secure codebase that’s closely monitored by the Drupal security team. Collectively, these make Drupal a highly safe CMS. But it doesn’t mean it is immune to vulnerabilities.

When using Drupal as our CMS, we must thoroughly understand web exploitation and implement best practices to secure our website. In addition to practicing the five security measures outlined here, we can implement website security scanning and vulnerability scanning to ensure our Drupal sites stay (safely) up and running.