Whenever we build something, we always ensure or at least hope that it doesn’t get damaged. Take our homes, for instance, we have more than a few locks at our places to protect and keep it secure. The same goes for our gadgets, our vehicles and most importantly our livelihoods. 

This brings me to the world of website development, wherein security is a major issue. An ill protected site is all but setting its demise, bugs and hacks will become its doom eventually. So, what should be done about it?

I have an answer and that is Drupal. 

Drupal, being a content management software, comes with an array of tools and features that protect its sites from every security breach. You will have to optimise Drupal properly to make that happen.

Drupal is one of the safest open source CMSs out there. 

These numbers are proof of the competence of Drupal's security measures. The entire responsibility of ensuring optimal security lies on Drupal security modules. And that is what we are going to be talking about today.

With the launch of Drupal 9, security has become all the more important. So, we’ll be discussing all the essential modules required for this task. I have taken the liberty to segregate the modules into eight categories, which will cover all the aspects of security that need to be looked into and protected to make a full-proof site. 

Let’s delve right in.

Tackling Brute Force 

A user logs onto your site, he has a strong enough password to protect his credentials, yet there are people who will keep trying to break that to gain access to your site. When these bad actors do that, you have to protect yourself from their Brute Force. If they gain access to your site, your entire project would be compromised and that would be an upsetting scenario. 

Tackling brute force starts with user registration, Drupal’s User Registration Password module allows users to register with a password while filling out the registration form, with a verification email. This module together with Password Policy ensures that the passwords set uphold the ideal standards with uppercase, lowercase, numbers and symbols at work.

What if your user wants to remain logged in?

That is an option with Persistent Login’s ‘Remember Me’ feature. However, you as an administrator can control how long those ‘Remember Mes’ live; meaning you could make a user sign in again after some time. You can also control which pages these users can and cannot access. 

There is also the option of Automated Logout, wherein an administrator can log a user out who has been inactive for quite some time.

Moving on, Secure Login is a module which ensures that the user logins and other forms are securely submitted without any transparency. With Login Security, you can protect and secure your site further with access controls. For another layer of security of individual pages, you can use Protected Pages, this module can secure any and all pages on your site with a password. 

Finally, you can also restrict the number of sessions by a user at one point, using Session Limit.

All of these together can make your website or application a force itself, which no brute can think of targeting.

Handling Authentication 

From brute force let's move onto authentication. Did you know that authentication is very different from authorisation? Authentication is the former step, wherein a user is identified and validated in regards to his claim over the site and its access points. The above talked about passwords are one way to authenticate a user. 

Once the authentication is done, authorisation swoops in. You know the person is an administrator, but what’s his grade? Can he be entrusted with sensitive information? Giving him the rights and liberties to access pages, data and any and all information is what authorisation is all about. 

How does Drupal handle it? 

Through its umpteen modules of course. Like I said before, a password is one of the best ways to authenticate, however, adding another layer of authentication with it becomes the best option of them all. Two-factor authentication and Google Authenticator Login provide you just that. While the former sends a code to the user’s mobile number, the latter works on a Time-based One-time password. Google Authenticator/ 2 Factor Authentication also provides similar functions. There is also the option of choosing Require Login, a module that aids in making user authentication on pages a mandate. 

If a user is authenticated with an external site or service and its authentication details are stored there, he can be logged in or registered with External Authentication. With Social Auth Google, users are authenticated using their Google accounts to your Drupal site. JSON Web Token can also be used as a factor to authenticate users through JSON Web Token Authentication. Drupal OAuth & OpenID Connect Login - OAuth2 Client SSO Login is a module that would allow any OAuth or OpenID Provider resident user to log in to your Drupal site. 

The authentication powers of SAML, OpenID Connect and Lightweight Directory Access Protocol can also be implemented with Drupal. SAML Authentication, SimpleSAMLphp Authentication, OpenID Connect and LDAP help in that respectively.

Social API is another module that can integrate with external services through a Social API. Using it would mean you can integrate modules for every authentication task.

What about IP addresses, is there any module pertaining to them?

Well, yes. You can very easily block access or simply ban certain IP addresses, if you want. Automatic IP ban and Advanced ban accomplish this feat conveniently, the former even has a watchdog table.

Finally, what about malicious attempts at authentication? 

Drupal has you covered there as well. There can be instances wherein certain bad actors try to identify valid usernames. This is called Username Enumeration and often leads to credential stuffing. However, Username Enumeration Prevention helps in avoiding that by stopping these anonymous users in their tracks.

Controlling Administration 

User access and authentication reminded me of the administrators and the role they play in accessing a site, which brings me to the next classification of security modules. Just like users can’t be granted access to everything on your site, the people building it also cannot be given total and complete reins over it. As there are permissions and restrictions for users, there are also for administrators. 

Let’s see what Drupal has to offer the administrators in terms of permissions and roles. 

Firstly, there is Permissions Filtered by Modules, this provides a filtered list of modules and roles at the top of the permissions page making management a breeze regardless of the number of roles. Then there is Administer Users by Role, which fine grains permissions even more to the level of sub-admins.

Next come the specific permissions and roles; Block Region Permissions and Block Permissions not only allow you to control access to administer blocks, but also pave way for finer grained validation in managing blocks, respectively. For adding, modifying and deleting items, an administrator can be given the permission from Menu Admin per Menu, specific to certain menus, or he won't be able to do that. You can also set permissions to fields related to authoring information and publishing options through Override Node Options. 

If you wish to disable User 1 to remove the administer user’s permissions, which allows them to edit their username and password, you can do it with Disable User 1 Edit.

Drupal also has another quite charming module, which I personally love. This is the Masquerade module, as the name suggests an administrator gets the power to switch users and surf the site as the switched user and without the need to enter a password. This helps a great deal in knowing the site’s outlook from the eyes of a client.

I would like to talk about Role Delegation here as well, it is a module that allows site administrators to assign roles to further authorise roles to users. 

Should we talk about user permissions and administrators control them? 

Yes, we should. There are two specific modules I want to mention here, one is View Unpublished. This allows an administrator to give access to user roles to view certain unpublished nodes. 

Second would be the Menu Item Role Access, which makes it possible to restrict certain items on a menu without the need for creating separate menus altogether. Isn’t that just great?

Intercepting Content 

Now it’s time for the content, who can access it, how it should be accessed and what should be accessed and what needs to remain restricted. 

Your content can be as secure as you want on Drupal. With its modules, you can easily manage your content without any worry of it reaching the wrong hands or eyes. Content Access will help you to manage access permissions. It's both flexible and transparent and would let you classify the permissions as ‘view all’ or ‘view own.’ Node View Permissions also works similarly with the same exact permissions.

Field Permissions helps site admins to set field level permissions for editing, viewing and creating fields for any kind of entity.

What about blocking content from certain users or admins?

There is a lot to talk about here as well. Let’s start with hierarchy, Workbench Access is a module that would allow you to create editorial access controls and guess what these controls would be based on? Yes, it's the work hierarchy. 

Then there is Block Content Permissions, with this you can control access to administer block content types and create, update and delete them whenever you want. There is also the option of blocking a node from being edited by two users at the same time, this can be done through Content Locking. 

You can also add a filter that would exclude pages from certain blocks, after or even in between a wildcard with Block Exclude Pages. If you are thinking about granting access to certain users so that they can view unpublished nodes and media, Access Unpublished can help you with that.

Another clever module is the 403 to 404, which displays the 404 error when a user tries to access a page that he doesn’t have the permission to access.

Implementing Encryption 

The majority of the files and messages on a website or its server are usually encrypted. This is done so that the unwanted eyes do not reach them. Can Drupal modules be serving this purpose? Of course. 

Your database is going to have several field values stored inside it, with Field Encryption module, you can store these values in an encrypted manner of your liking. You create your own encryption method with this. 

What about the key?

There is a module with the same name. Key helps in managing all sensitive keys including APIs and encryption keys, of course. You, as an administrator, can take command over how and where these keys would be stored, making the security of the same pretty efficient. 

Is there a module that does both? Encryption and decryption?

There certainly is. You can perform symmetric and asymmetric encryption with Drupal. You can integrate modules to perform encryption and decryption in a standardised way. You can also have any number of encryption profiles used by any number of modules. And you can do this with the Encrypt module. 

You can also use the power of AES encryption with the Encrypt module. For that, you would have to combine Real AES with the former and gain access to Defuse PHP-Encryption Library.

Fighting Spam 

Unwanted and unsolicited is what spam is. It may seem like nothing beyond a nuisance, but it can become more if the web builders become complacent. Spam is capable of infecting your site with malicious software and you must know that that can never have a positive outcome. Lucky for you, Drupal is capable enough to never let that outcome take place. 

When we think about spam, a few things instantly pop up in our minds, these would be emails, comments, registrations, messages, feedback and contacts. Usually getting all of these is a good sign for your growth, but when it's spam written all over them, the good doesn’t take long to go bad. 

Honeypot and Antibot are two of the more popular modules for eliminating robotic form submissions with close to 150,000 and 33,000 Drupal sites using them for this purpose. 

Drupal modules like Spam Master, Protected Submissions, Anti Spam by CleanTalk, Check DNS, Drupal Perimeter Defence, Spambot and Spamicide, also aid in deterring the intrusion of spam on your site. Talking about Spamicide, which is pretty clever in itself, it’s a module that adds a field to forms and then hides them. So, when a bot is filling that registration form, it’d probably fill in that field and when that happens you simply discard that form and rid yourself of its nuisance. 

For email obfuscation, SpamSpan Filter and Obfuscate come in handy and prevent spammers from collecting them. E-mail No-Reply is also a great module that allows you to create a field with no reply addresses, yet still, receive important notifications from Drupal. 

What about the troubling IP addresses?

Flood Control is a Drupal module that allows you the functionality of an interface that makes it very convenient to remove IP addresses as well as user IDs from the flood table.

Can we really talk about Spam and not mention CAPTCHA?

Today, almost every web form has a CAPTCHA challenge at the end right before the submission is final, only to trick the spammers and bots. A CAPTCHA would be very easy for a human, but very confusing for a bot. This is an age-old trick to manoeuvre spambots entry to your site. Drupal has both CAPTCHA and ReCAPTCHA modules available for the taking.

CAPTCHA and ReCAPTCHA are the front runners here, equipped with the right challenges to handle spambots.

Simple Google ReCAPTCHA with its checking the ‘I’m not a robot’ box is pretty good as well. Google ReCAPTCHA v3 provides you with a score for those requests without any friction. Recaptcha Element provides further integration with Google reCAPTCHA v3.

There is also hCaptcha, a module that helps in labelling large proportions of data within a stipulated time as well as being affordable and reliable.

Attacking Hacks

Your website is somehow going to end up being a target for hackers and you can’t avoid that from happening. All you can do is make sure that it is protected to the nth degree when that happens. 

Using Drupal’s Security Kit is the first step in hardening your security. It protects from various security threats and keeps your vulnerabilities at bay from exploitation. Cross-site scripting, cross-site request forgery, clickjacking and SSL/TLS are some of the attacks prevented by this module. Content Security Policy works on a similar principle; it informs browsers of trusted sources to mitigate hacks and add an additional security layer on top.

If you want a reverse proxy and firewall for protection against hacks, then CloudFlare would be the right choice. 

System Status is another module that does everything from eliminating security vulnerabilities to performing necessary upgrades to keep your site hack-proof.

Dealing with the Rest 

Up until now, we have covered all the major aspects of security, from permissions and authentication to spam and hacks, yet there are still some modules left to discuss that have a role to play in Drupal security. We’ll discuss that now. 

Let’s start with the laws. General Data Protection Regulation sets the guidelines that govern how data is protected as well as the privacy of the users in the EU. Drupal’s GDPR module provides helper tools that in turn aid your sites in becoming more compliant with this law. Cookiebot further aids in tracking your use of cookies and GDPR and ePR compliance. Then there is TacJS, which helps your sites in adhering to the European Cookie Law with the user of tarteaucitron.js.

Moving on, to ensure that all uploaded files are sound and secure, you can use File Upload Secure Validator, which does exactly what its name suggests; validating the security of the uploaded files on the server-side. ClamAV further ensures that those files are not infected by any virus by integrating Drupal with the virus scanner of the same name.

For headers and referrers, there are the Remove HTTP Headers and No Referrer modules. While the former removes the HTTP headers from the configuration, the latter ensures that no referrer information is leaked.

Security.txt helps in implementing the security.txt standard, which ensures the proper documentation of your site’s security contacts and policy. There is a module to avoid stale IP addresses clogging up your database and protecting user’s privacy, this can be done through IP Anonymize. 

Finally, to ensure that your site is at the prime of its health, you can opt for Health Check, which would enable you with an endpoint for the load balancers. 

Conclusion 

So, there you have it, the majority of the Drupal security modules that would make your Drupal site watertight. I wouldn’t say that there aren’t any other modules for security, there certainly are and you would be wise to use them as well. 

In the end, I’ll just say that security is always going to be a primary concern when websites are built and made operational. Drupal isn’t a software that would be described as lacklustre in terms of security and with the launch of Drupal 9, security has become all the more efficient at Drupal.