Drupal hardening for organisations: security configurations that reduce the attack surface
By Kike Gandia · Co-Founder & CEO, OSCP
Drupal hardening sets the security baseline of the installation: configurations that reduce the visible attack surface before any exploitation attempt occurs. For organisations using Drupal in critical contexts —public administrations, universities, media outlets, healthcare portals— the right configuration is the first barrier.
Hardening the permissions and roles system
Drupal has a granular roles and permissions system that, when misconfigured, leads to privilege escalation between editorial roles. Hardening includes: reviewing all permissions assigned to anonymous and basic authenticated roles, verifying that editorial roles have no access to PHP functions (the PHP filter module is a critical risk), and auditing custom roles that may have accumulated unnecessary permissions over time.
Hardening the site configuration
settings.php file: It must have 444 permissions and not be writable by the web server. It contains database credentials and environment configuration. A /sites/default/settings.php file accessible from the outside is a critical finding in any audit.
Trusted host patterns: The trusted_host_patterns setting in settings.php prevents HTTP Host header injection attacks. Many installations leave it empty or far too permissive.
Base URL and debug mode: Error reporting in production that exposes server paths, the PHP version and the file system structure must be disabled. Drupal's debug mode should never be active in production.
Hardening modules and updates
The Drupal security team publishes Security Advisories through a structured process. Organisations running Drupal in critical contexts must have a formal process to track and apply security patches within a maximum of 48-72 hours for critical advisories.
Drupal's Update Manager module notifies you of available updates, but does not prioritise by criticality. For organisations with many contrib modules, managing the patching cycle requires a process of their own.
What hardening covers and what it does not
Hardening reduces the attack surface, but it replaces neither patching nor code review. It is worth being clear about which risk each thing closes before calling an installation secure.
| Risk | Does hardening cover it? | What else is needed |
|---|---|---|
| Contrib module with a known vulnerability | No, it only reduces exposure | A patching process tracking the advisories |
| Escalation between editorial roles | Partly | Review of effective permissions, role by role |
| Flaw in a custom module | No | Code review |
| settings.php writable or reachable | Yes | — |
| Host header injection | Yes, with trusted_host_patterns | — |
| PHP errors visible in production | Yes | — |
| Reused credentials from an editor | No | Second factor and password policy |
| Uploaded content executed as PHP | Yes, by blocking execution in the files directory | — |
The practical reading: hardening closes configuration problems well —there are many and they are cheap to fix— and touches neither code nor process problems, which are the ones that end up causing the incident.
Files and paths worth checking by hand
There is a set of checks that need no tooling and that show up again and again in audits of otherwise well-maintained installations.
- The uploaded files directory (/sites/default/files) must not allow PHP execution. That is the difference between an annoying file upload and remote code execution.
- Core CHANGELOG.txt files reveal the exact version and should be out of public reach.
- /update.php should not be reachable without authentication.
- Open user registration on a site where nobody should be registering is a more frequent finding than it sounds.
- Forgotten copies in the docroot: settings.php.bak, settings.local.php, .sql dumps, .patch files and folders from old deployments.
- An exposed .git directory hands over the code and, frequently, credentials from its history.
- Site status reports reachable without authentication summarise the version and installed modules for an attacker.
None of these checks takes more than a few minutes, and each one closes a reconnaissance path the attacker uses before choosing an exploit.
FAQ
Does Drupal's Security Review module cover all hardening?
The Security Review module automates the verification of some basic configuration controls, but it does not detect complex permission logic issues, vulnerabilities in custom modules or server configurations. It is a starting point, not a substitute for an audit.
How long does it take to apply hardening to an enterprise Drupal installation?
Between 1 and 3 days depending on the size of the installation, the number of modules and the complexity of the roles. The time increases if there are custom modules that require code review.
Can hardening break site functionality?
Some settings can, which is why they are applied in pre-production before production. The ones that generate the most friction are blocking PHP execution in the files directory when a module depended on it, restricting permissions on editorial roles that had held more than necessary for years, and trusted_host_patterns if the site answers on more domains than the team remembers.
How often should the hardening baseline be reviewed?
A review makes sense after every significant change —a major core update, a deployment adding modules, a change of hosting or CDN— and periodically even without changes, because configurations degrade on their own: somebody adds a role, somebody leaves a debug file behind, somebody widens a permission to get unblocked and never reverts it.
If the site is already compromised, does hardening fix it?
No. Hardening makes entry harder, but it does not remove what the attacker already left inside: created users, modified modules, added PHP files or scheduled tasks. With a confirmed compromise, the right order is incident response first —preserve evidence, establish the entry path and clean up— and hardening afterwards, so it does not happen again by the same route.