Drupal security audit: technical analysis for institutional and enterprise organisations
By Kike Gandia · Co-Founder & CEO, OSCP
Drupal is the CMS of choice for public administrations, universities, media outlets and complex organisations that need advanced control over content, roles and publishing workflows. Its robustness as a platform does not eliminate security risks: third-party modules, custom configurations and the complexity of the environment are attack vectors that require specific analysis.
Drupal in complex organisations: a specific attack surface
A typical enterprise Drupal installation includes dozens of contrib modules, custom development, integrations with internal systems (LDAP, SSO, ERP), complex user roles and a hosting environment that may span multiple servers, CDNs and load balancers. This complexity widens the attack surface beyond what a generic analysis can cover.
Drupalgeddon (CVE-2014-3704) and Drupalgeddon2 (CVE-2018-7600) are the best-known examples of critical core vulnerabilities with massive impact. But most current Drupal compromises occur through outdated contrib modules or misconfigurations.
What a Drupal security audit covers
- Core and contrib module versions against the Security Advisories history from the Drupal security team
- Analysis of custom modules: PHP code, hooks, forms, database access and permission control
- Review of Drupal's roles and permissions system: configuration complexity and possible privilege escalation
- Testing of the login form and authentication system: brute force, enumeration and bypass
- Analysis of Drupal's REST API and JSON:API: endpoints accessible without authentication and access control
- Review of integrations: LDAP/Active Directory, SSO (SAML, OAuth), file systems and external storage
- Server configuration: file permissions, access to sensitive directories (/sites/default/settings.php) and HTTP headers
Compliance and ENS in public organisations running Drupal
Spanish and European public administrations that use Drupal are subject to the National Security Framework (ENS) or equivalent regulations. A Drupal security audit produces the technical pentesting evidence required for ENS certification processes and to meet the standard's web application security controls.
Core, contrib, custom code and configuration: where the risk really sits
Talking about "Drupal security" as a single block leads to spending the effort in the wrong place. Each layer has a different owner, a different dominant risk and a different way of being covered.
| Layer | Who maintains it | Dominant risk | How it is covered |
|---|---|---|---|
| Drupal core | The Drupal security team | The window between the advisory and your deployment | A patching process with an owner and a committed deadline |
| Contrib modules | Volunteer maintainers, with uneven commitment | Modules with no active maintainer, or outright abandoned | An inventory recording each one’s maintenance status |
| Custom modules | You or your supplier | They have never been through a security review | Code review over hooks, forms and queries |
| Configuration and permissions | Your team | Permissions accumulated role by role over years | Review of effective permissions, not the ones people believe they have |
| Integrations (LDAP, SSO, ERP) | Shared | Implicit trust in an external identity | Authentication and authorisation testing at the boundary |
In practice, the layer generating the most findings in large organisations is not core —which tends to be reasonably current— but the combination of abandoned contrib and accumulated role permissions.
How it fits with ENS and what evidence remains
For a public administration or an entity subject to the Spanish National Security Framework, the audit is not only a technical exercise: it has to leave a trail usable in the compliance process and before the certification auditor.
To be usable, the report must make clear the exact scope (which environments, which domains and what was left out), the execution dates, the methodology followed and its reference framework, each finding with reproducible evidence and its classification, and the remediation plan with owners. The subsequent re-test closes the loop: it documents what was fixed and what remains open, with justification. It is worth remembering that a technical audit provides evidence for web application security controls, but does not certify on its own: certification is issued by an accredited body over the system as a whole.
FAQ
Is the audit compatible with Drupal 7, 9 and 10?
Yes, although Drupal 7 has reached official end of support. If your organisation is still on Drupal 7, the audit documents the version-specific risk of running EOL software and prioritises migration as part of the remediation plan.
Does the audit include a review of the workflow and publishing modules?
Yes. Workflow, content moderation and publishing modules are components with complex access-control logic that may contain privilege escalation between editorial roles.
What does a Drupal site audit evaluation actually deliver?
A prioritised findings report (each issue rated by exploitability and business impact), proof-of-concept evidence for anything exploitable, and a remediation plan mapped to your module/contrib inventory — not just a vulnerability scan output. A free re-test after fixes is included.
Do you need administrator access to the site?
For the black-box part, nothing is needed. To review effective permissions, roles and configuration, accounts with whatever profiles exist are required —including an administrative one— because many escalations between editorial roles are only visible from inside. Everything is agreed in writing before starting, and the work preferably runs against an environment equivalent to production.
Can it be done against pre-production instead of production?
That is the recommended approach, provided the environment is genuinely equivalent: same modules, same versions, same role configuration and integrations. The usual difference lies in server configuration and in the real integrations, so that part is normally verified passively against production while active testing runs in pre-production.
What happens if you find something critical mid-audit?
It is reported immediately, without waiting for the final report. A finding that allows the site to be compromised or personal data to be reached is reported as soon as it is confirmed, with the minimum information you need to mitigate it that same day, and documented afterwards with the rest. Holding a critical finding until delivery has no justification.