Drupal has one of the strongest security track records of any open-source CMS. The Drupal Security Team publishes advisories, maintains a defined response process, and has built security review into the module release process in ways that many platforms have not. The platform is designed to be secure.
That security does not maintain itself. It depends on how the site is built, how it is hosted, and whether it is actively maintained. An outdated Drupal installation with unpatched vulnerabilities is not a secure site simply because it runs on Drupal.
The Security Team and the Advisory System
Drupal’s Security Team reviews reported vulnerabilities, coordinates with module maintainers, and publishes advisories on a regular Wednesday schedule. Security releases for Drupal core and contributed modules are published with a severity rating and clear remediation instructions.
This system is only useful if someone is monitoring it and acting on it. Organizations that receive security advisories and apply updates promptly are protected. Organizations that do not notice advisories, or notice them and defer action, accumulate known vulnerabilities. Those vulnerabilities are publicly documented — which means anyone looking for a way in can look them up.
Keeping Core and Modules Updated
The most important security practice for any Drupal site is prompt application of security updates. This includes:
Drupal core. Security releases for Drupal core are published as patch versions (for example, 11.x.1 to 11.x.2) on a regular schedule. Applying these promptly — within days of release for sites with public exposure — is the baseline.
Contributed modules. Every installed contributed module is a potential vulnerability surface. Modules that are not actively maintained do not receive security updates. Modules that are maintained release security updates that need to be applied.
Drupal CMS’s Automatic Updates. Drupal CMS includes the Automatic Updates module, which can apply core security releases automatically. For organizations that do not have a managed update process in place, this substantially reduces the window between security release and application.
User Roles and Permissions
Drupal’s permission system is granular and powerful. That granularity is only useful if it is configured correctly.
The principle of least privilege applies directly: every user role should have exactly the permissions it needs and no more. Content editors do not need access to site configuration. Site builders do not need access to user administration. Administrators who do not need to manage the server do not need hosting credentials.
Review user roles and permissions when the site is built, when roles change, and when users leave the organization. Permissions that accumulate through role changes or personnel transitions are a common source of over-provisioned access.
Admin account credentials should use strong unique passwords and two-factor authentication. The admin user account should not be used for day-to-day content editing — operational access should be through appropriately permissioned role accounts.
HTTP Security Headers
HTTP security headers are instructions sent by the server that tell browsers how to handle the site’s content. They protect against common attack vectors including cross-site scripting (XSS), clickjacking, and protocol downgrade attacks.
The headers that matter most: - Content Security Policy (CSP): Controls which sources can load scripts, styles, images, and other resources on the page - Strict-Transport-Security (HSTS): Forces browsers to connect via HTTPS and prevents protocol downgrade attacks - X-Frame-Options: Prevents the site from being embedded in iframes on other domains, blocking clickjacking - X-Content-Type-Options: Prevents browsers from interpreting files as a different MIME type than declared - Referrer-Policy: Controls what referrer information is sent with requests
These headers are configured at the server or reverse proxy level, not in Drupal itself. A Drupal site on infrastructure that allows this configuration can have these headers set correctly. A site on hosting that does not expose this configuration cannot.
Contributed Module Selection
Every contributed module installed on a Drupal site adds to the attack surface. Module selection decisions are security decisions.
Modules should be evaluated for active maintenance status before installation. An abandoned module that has not received updates in two or more years is a liability — if a vulnerability is found, no one will patch it. The Drupal project page shows the last release date and open issue queue, which together indicate whether a module is actively maintained.
Installing only modules that are actually needed reduces the attack surface. Modules that were installed for a feature that is no longer used should be uninstalled and removed.
Hosting and Infrastructure Security
Drupal’s application-level security is only as strong as the infrastructure it runs on. Hosting decisions that affect security include:
PHP version currency. Running a current, supported PHP version (8.3 for Drupal 11) is a security requirement, not a preference. Unsupported PHP versions do not receive security patches.
Web Application Firewall (WAF). A WAF filters malicious traffic before it reaches the Drupal application. It can block common attack patterns — SQL injection attempts, XSS payloads, brute force login attempts — that Drupal’s application layer would otherwise have to handle.
SSL/TLS configuration. HTTPS is table stakes. The SSL/TLS configuration should use current cipher suites and protocol versions. Tools like SSL Labs’ server test identify configuration weaknesses.
File permissions. Files on the server should have permissions that allow the web server to read them without allowing arbitrary writes. Writable files outside the designated files directory are a risk.
Server log access. Security incidents require investigation. The ability to access server logs — to see what requests were made, what errors occurred, and what patterns preceded an incident — is a prerequisite for meaningful incident response.
File Upload and Form Security
Drupal sites that accept file uploads need to validate the files being uploaded: file type, size, and content. Allowing arbitrary file uploads without validation is a common vulnerability.
Forms that accept public submissions need protection against automated abuse: CAPTCHA for contact and registration forms, rate limiting for login attempts, and honeypot fields to catch simple bots. Drupal CMS includes anti-spam tools in the drupal_cms_anti_spam Recipe.
Regular Security Audits
Beyond ongoing maintenance, periodic security audits identify gaps that routine updates do not address: permission configurations that have drifted over time, third-party scripts that have accumulated, security header configurations that have not been reviewed, modules that have become abandoned.
An external audit is more reliable than an internal review for identifying issues that have become invisible through familiarity.
How Cool Fire Approaches Drupal Security
Cool Fire Inc builds and maintains Drupal platforms with security as a component of the ongoing maintenance process, not a separate concern. Managed support engagements include security update monitoring and prompt application as a standard component.
Frequently Asked Questions
Is Drupal secure out of the box?
Drupal core is built with security as a design principle and has a strong track record. Out-of-the-box security depends on the installation configuration — user roles, file permissions, and HTTP headers all require correct setup. Security is also ongoing: a well-configured Drupal site that is not kept updated will accumulate vulnerabilities over time.
How often does Drupal release security updates?
Core security releases are published on a regular Wednesday schedule when vulnerabilities are identified, typically one to four times per month across core and contributed modules. Contributed module security releases are published on the same schedule. Organizations should monitor the Drupal security advisories feed and apply updates promptly.
What is the Drupal Security Team?
The Drupal Security Team is a volunteer group that receives vulnerability reports, works with module maintainers to develop fixes, and publishes advisories. It operates a responsible disclosure process — vulnerabilities are not published until a fix is available — and coordinates the timing of security releases to give site owners time to prepare.
Do contributed modules have security review?
Modules in Drupal’s official project directory go through a review process before they are granted “full project” status. That review includes a security check by a Drupal Security Team member. However, the review is a point-in-time check, not ongoing monitoring. Module security depends on active maintenance after the initial review.
What should I do if my Drupal site has been compromised?
Take the site offline or put it in maintenance mode immediately to limit ongoing damage. Preserve logs before any cleanup — they contain information about how the compromise happened. Contact a Drupal security specialist to investigate, clean the site, and identify the vulnerability that was exploited. Apply all pending security updates before bringing the site back online. If user data was exposed, consult legal counsel about notification requirements.