Drupal has earned a reputation as one of the more secure CMS platforms available. Its dedicated security team, structured release process, and security advisory system set it apart from many alternatives. But "more secure by default" does not mean "secure without effort." I regularly scan Drupal sites through BlackSight that have up-to-date core installations but are riddled with misconfigurations, overly permissive roles, and contributed modules with known vulnerabilities.

Keeping Drupal core updated is step one. This article covers steps two through ten — the hardening measures that separate a properly secured Drupal site from one that just happens to be running the latest version.

1. Understanding Drupal Security Advisories and the SA System

Drupal's security advisory system is one of the best in the CMS ecosystem. The Drupal Security Team reviews reported vulnerabilities, coordinates with module maintainers, and publishes advisories on a regular Wednesday schedule. Each advisory is classified by severity — Critical, Moderately Critical, Less Critical — and includes the affected versions, a description of the vulnerability, and the fix.

Advisories follow a naming convention: SA-CORE for Drupal core issues and SA-CONTRIB for contributed modules. Subscribe to the security mailing list or follow @daborobot on social media for immediate notifications. When a security advisory marked "Highly Critical" drops, you need to patch within hours, not days. The Drupalgeddon vulnerabilities (SA-CORE-2014-005 and SA-CORE-2018-002) demonstrated that attackers begin exploiting critical Drupal vulnerabilities within hours of public disclosure.

Do not assume your hosting provider patches for you. Managed Drupal hosts often handle core updates, but contributed module advisories are your responsibility. Check status at /admin/reports/updates regularly.

2. Module Vetting and the Security Coverage Badge

Not all contributed modules are created equal. Drupal.org displays a green "Covered by the security advisory policy" badge on modules that have opted into the security team's review process. This means that if a vulnerability is found in the module, it will be handled through the formal advisory process rather than being quietly fixed or ignored.

Before installing any contributed module, check for this badge. If a module does not have security coverage, you are accepting the risk that vulnerabilities might go unpatched or undisclosed. For critical functionality, this risk is unacceptable.

Beyond the badge, evaluate modules by their maintenance status. When was the last commit? How many open issues exist? Is the maintainer responsive? A module abandoned two years ago with 30 open bug reports is a security liability regardless of its badge status. Fewer modules means fewer attack surfaces — remove any module you installed to "try out" and never actually use.

3. Permissions and Roles Hardening

Drupal's permission system is granular and powerful, which means it is also easy to misconfigure. The most common mistake I see is giving the "Authenticated user" role too many permissions. Every registered user on your site inherits these permissions, and if you allow user registration, that means anyone.

Review permissions at /admin/people/permissions with a critical eye. The "Administer" permissions for any module should be restricted to administrators only. The "Use PHP for settings" permission (if the PHP module is enabled, which it should not be) gives users the ability to execute arbitrary code. The "Administer text formats and filters" permission allows users to create text formats that can bypass security filtering.

Create specific roles for each user type on your site — editor, content reviewer, site builder — and grant only the permissions each role actually needs. Never give a role permissions "just in case." Audit permissions quarterly. When a module is installed, it often adds new permissions that default to unchecked — verify that they stay that way unless explicitly needed.

4. Securing settings.php

The settings.php file is the most sensitive file in your Drupal installation. It contains your database credentials, hash salt, and critical configuration. Hardening it properly is essential.

First, set the trusted_host_patterns setting. Without it, Drupal accepts requests for any hostname that resolves to your server, which enables HTTP Host header attacks used in cache poisoning and password reset hijacking:

Second, move sensitive credentials outside of settings.php where possible. Use environment variables or a separate settings.local.php file that is excluded from version control. Your database password should never be committed to a Git repository.

Third, set file permissions correctly. settings.php should be read-only (444 or 440) after installation. The sites/default directory should be 555 or 750. Drupal's status report at /admin/reports/status will warn you if these permissions are wrong — do not ignore those warnings.

5. Input Filtering and Text Formats

Drupal's text format system is a critical security layer. Each text format defines which HTML tags and attributes are allowed in user-submitted content. The "Full HTML" format allows nearly everything, including script tags. The "Restricted HTML" and "Basic HTML" formats strip dangerous elements.

Never assign the "Full HTML" text format to untrusted roles. If a content editor can use Full HTML, they can inject JavaScript that executes for every visitor to that page. This is stored XSS — one of the most dangerous vulnerability types because it persists and affects all users.

Review your text formats at /admin/config/content/formats. For most content roles, "Basic HTML" with a limited set of allowed tags is sufficient. If editors need more formatting options, use CKEditor's built-in filtering rather than expanding the allowed HTML tags. The "Plain text" format is the safest option for user-generated content like comments.

Drupal's Twig templating engine provides automatic output escaping by default, which is a major security improvement over Drupal 7's PHPTemplate. However, using the raw filter or the safe_markup type in custom code bypasses this protection. Audit any custom Twig templates for these bypasses.

6. Admin Path Protection and Access Restriction

Drupal's admin paths are predictable: /admin, /user/login, /user/register. Attackers know this and target these paths with brute force attacks, credential stuffing, and vulnerability exploits. While security through obscurity is not a real defense, reducing exposure to automated attacks is practical risk reduction.

Consider restricting access to admin paths by IP address at the web server level. If your team always accesses the site from known IP ranges or a VPN, block admin path access from all other IPs in your Nginx or Apache configuration:

Install rate limiting for login attempts. The Flood Control module or server-level tools like fail2ban can lock out IPs after repeated failed login attempts. Drupal core has built-in flood protection, but its default thresholds (five failed attempts before a temporary lock) may be too permissive for high-value targets.

Disable user registration if your site does not need it. If you do need public registration, add CAPTCHA to the registration form and enable email verification. Open registration without protection is an invitation for spam accounts and automated attacks.

7. Removing update.php and install.php

After your site is installed and running, the install.php and update.php scripts at your document root represent unnecessary risk. install.php can be used to reinstall Drupal if accessed at the right time, and update.php runs database updates that could be triggered by an attacker who has bypassed authentication.

Drupal protects update.php with an access check that requires the $settings['update_free_access'] setting to be FALSE, which it is by default. However, defense in depth means not relying on a single control. Block direct access to these files at the web server level:

For update.php, use Drush or the admin UI to run database updates instead. For install.php, there is never a reason to access it on a production site. Blocking these files at the web server adds a layer of protection that survives application-level misconfigurations.

8. Drupal's Security Team and Responsible Disclosure

If you discover a security vulnerability in Drupal core or a contributed module, do not post it in the public issue queue. Drupal has a formal responsible disclosure process. Report vulnerabilities to the Drupal Security Team through the dedicated form on drupal.org.

The security team coordinates the fix, works with the module maintainer, and times the public disclosure with the patch release. This process protects the entire Drupal community by ensuring fixes are available before exploits become public knowledge.

For your own Drupal sites, establish an internal vulnerability disclosure process. Make it easy for your developers, contractors, or even external researchers to report issues they find. A security@ email address that someone actually monitors is the minimum. Responding constructively to reports — instead of threatening legal action or ignoring them — is how mature organizations handle security disclosures.

Keeping Drupal secure is not a one-time project. It is an ongoing practice. Apply core updates promptly, vet your contributed modules, lock down permissions, harden your configuration, and scan regularly. Use BlackSight's CMS scanner at scanner.blacksight.io to identify Drupal-specific issues that manual review might miss. The platform detects outdated core versions, exposed configuration files, missing security headers, and common Drupal misconfigurations automatically.