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.
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.