Drupal core has a good security record. Sites are compromised through what sits around it: a contributed module behind a published security advisory, a role with more permission than anyone meant to grant, a file directory the web server is willing to execute. This audit is a structured pass over those places, with the source code and configuration in front of us, and it ends in findings ranked by severity with the effort to fix each one. You keep the report whether or not we do the remediation.
Layers a Drupal security audit covers From your own code down to the server
Custom code Your modules and theme, read with the source in front of us
Built on
Core and contributed modules Checked against published security advisories
Composer libraries Including the ones pulled in indirectly
Configured by
Configuration Roles, permissions, text formats, files and APIs
Served by
Server TLS, security headers, exposed paths and error display
Who this is for
- You have just taken over a Drupal site. You now own a codebase you did not write, and both sides need to know what is in it before anyone agrees a support arrangement.
- The site is about to go live. Permissions, file handling and dependency versions are cheapest to fix before real content and real users arrive.
- There has been an incident. Once the site is contained, the audit establishes how it happened and what else is exposed.
- A review is due. Your insurer, board or procurement rules ask for one at a set interval, or the architecture, hosting or team has changed since the last one.
Not sure a security audit is the right place to start? A Drupal site audit is the entry point that looks across security, module compatibility, accessibility, hosting and performance, and points to the review worth doing next.
What you get from a security audit
- One report, classified so that it can be triaged rather than read end to end
- Every finding with where it is, what it would allow, the fix and an effort estimate
- Findings ranked Critical, High, Medium or Low, by what an attacker could actually do
- Unsupported modules reported apart from out-of-date ones, because the remedy differs
- A plain statement of what we did not test
- An order of work that closes the most exposure for the least effort
Sample Security audit findings example.org · Drupal 10.3
- Critical Exploitable now
- High Exploitable with some access
- Medium Weakens a defence
- Low Hardening
-
Critical
SEC-01DependenciesA contributed module is behind a published security release
- Where
composer.lock, the file upload module- Fix
- Update to the patched release and run the regression suite.
- Effort
- Hours
-
High
SEC-02ConfigurationUntrusted users can post with a text format that allows scripts
- Where
- Text formats, Full HTML granted to the Authenticated role
- Fix
- Limit the format to trusted roles and review existing content.
- Effort
- Under a day
-
Medium
SEC-03ServerSecurity headers are missing
- Where
- Web server configuration
- Fix
- Add Content-Security-Policy and Strict-Transport-Security, then test the editor.
- Effort
- Half a day
-
Low
SEC-04ConfigurationError messages are shown to visitors
- Where
- Logging and errors settings
- Fix
- Log errors, display none on production.
- Effort
- Minutes
The effort estimates are the part clients use most: they turn a security report into a budget conversation instead of an argument.
An engineer reads it and replies within one business day.
How a Drupal security audit runs
How a Drupal security audit runs
- Scope Codebase, environments and integrations agreed, with what is out of scope written down. You keep the scope statement
- Copy We work on a copy: the code, a sanitised database and read access to configuration. Production stays yours
- Review Each layer checked by hand and with tooling, from custom code to server headers.
- Report Findings ranked by severity, each with where, fix and effort. You keep the report
- Walkthrough We take your developers through any finding they want explained, at no charge. You keep the order of work
What is in scope: Drupal hardening, layer by layer
The audit follows the routes a Drupal site is actually attacked through, and each item below doubles as a hardening check you can hold the site to afterwards:
- Core and contributed module currency. Every installed module read against the Drupal security advisories (SA-CORE and SA-CONTRIB), including modules abandoned upstream that will never receive another fix.
- Composer dependencies. The libraries under Drupal, audited for known vulnerabilities, including dependencies nobody chose that arrived with something else.
- Roles and permissions. Every role read against what it can actually do. An editor role that can administer text formats, or an authenticated-user permission meant for staff, is usually the most serious finding and the least expected.
- User accounts. Dormant administrators, shared logins, accounts of people who have left, and whether a new administrator could appear without anybody noticing.
- File handling. Upload validation, what the private file directory really protects, and whether anything in a writable directory can be executed.
- Forms and input. Which roles reach the permissive text formats, flood and spam controls, and custom handlers that build queries or markup themselves, checked against the injection and cross-site scripting classes in the OWASP Top 10.
- APIs and integrations. Exposed REST and JSON:API resources, the authentication on each, what a leaked key could do, and whether credentials sit in configuration that ends up in version control.
- Environment and transport. TLS, security headers, error display in production, database and cache exposure, and whether update and admin paths answer from the public internet.
For each contributed module we also read its release history and issue queue, which is where abandonment shows first. We maintain contributed modules on drupal.org ourselves, among them WE Mega Menu, so we read those signals from the maintainer's side.
An audit is not maintenance
The two solve different problems. Patching will never find a role that was over-permissive on the day maintenance started, and an audit does not keep a site current once it is done.
| Question | Security audit | Maintenance |
|---|---|---|
| What it does | Reviews the shape the site is in: permissions, configuration, code and dependencies | Keeps the site current: security releases, dependency updates, backups and monitoring |
| When | At a point in time, and again after a significant change | Continuously, while the agreement runs |
| What it finds | Problems patching never touches, such as a role with too much permission | New advisories as they are published |
| What you receive | A findings report ranked by severity | Updates applied, and a record of them |
| How it is paid | A fixed price, quoted before it starts | A monthly agreement |
If you are buying both, the audit first is the cheaper order: a monthly fee quoted without knowing what is in the codebase is a guess that gets corrected later. Ongoing patching is described on Drupal support and maintenance.
Remediation, and who does it
Findings are quoted for separately, once they exist, so the audit is never a sales instrument with its conclusion decided in advance. The order we recommend is rarely severity alone: module updates that close several advisories at once usually come first because they are cheap, then the permission model, then anything that needs code changes.
Where the underlying cause is an unsupported Drupal version, the fix is an upgrade rather than a patch, and we will say so rather than sell a month of patching that cannot work. Drupal 10 reaches end of life on 9 December 2026; after that date a currency finding on core has only one fix.
Keeping fixes in place afterwards is maintenance work, the same work we do on the sites we built and still look after, where security releases for core and contributed modules are applied as they are published. Your own team is equally welcome to do the remediation: the report is written for a developer who was not in the audit.
What a Drupal security audit costs
The audit is scoped from the size of the codebase, the number of contributed and custom modules, and how many environments and integrations are in scope. It is a single piece of work, quoted at a fixed price before it starts. Remediation is quoted separately, against the findings.
On the pricing page, security audit and remediation work is listed under maintenance and support, next to the monthly agreements that keep a site patched afterwards. A site we did not build starts the same way whichever you choose: with a look at what is actually in it.
Terms that hold
These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.
- A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
- You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
- A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
- Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.
Questions we get asked
Is this a penetration test?
No, and the distinction matters when a buyer asks. A penetration test attacks a running system from the outside to prove exploitability. This is a white-box review of the code, configuration and permissions with the source in front of us, which finds a different and usually larger set of problems. If your requirement is specifically a penetration test by an accredited tester, we will tell you so rather than sell you this instead.
Can you audit a site you did not build?
Yes. A site nobody on your side built is where an audit is most useful, because nobody currently holds the whole picture of it.
We think we have already been compromised. What now?
Say that when you contact us, because the first hours are handled differently: containment and preserving evidence come before any review. An audit run on a live compromise both destroys forensic evidence and answers the wrong question.
Do you need production access?
We prefer a copy: the codebase, a sanitised database, and read access to the configuration. Some findings (TLS, headers, exposed paths) need the production hostname, but that is observation from outside rather than access to it. Where production access is genuinely needed we ask for the narrowest account that will do the job, and it is revoked when the audit ends.
What if the findings are embarrassing?
They usually are, for whoever built it, and almost never for the person who commissioned the audit. The report describes the system, not the people. We work under NDA as a matter of course, and the findings go to you and to nobody else.
Our Drupal version is out of support. Is an audit still worth it?
Yes, but expect the headline recommendation to be the upgrade, because on an unsupported version core currency findings have no other fix. The audit is still what tells you how exposed you are in the meantime, and which of the other findings are worth money before the upgrade lands.
How often should we repeat it?
At whatever interval your insurer, board or procurement rules ask for, and again after any significant change of architecture, hosting or team. Patching is continuous and belongs to maintenance, not to the audit.
How long does it take?
It scales with the number of contributed and custom modules, the amount of custom code, and how many environments and integrations are in scope. We give you that figure with the quote, before you commit.
Not covered here? Ask us directly.
Request a security auditAn engineer reads it and replies within one business day.
Migrate & Audit
Related services
Find out what is actually in there
Tell us the site and why you are asking. The findings are yours whether or not we do the remediation.
An engineer reads it and replies within one business day.