What a Drupal security audit covers
A Drupal security audit is a point-in-time, timeboxed review of a Drupal platform against known classes of security risk: access control, dependency posture, configuration, code, infrastructure and edge protection. It produces rated findings and a prioritized remediation plan.
An audit does not make a platform secure, and no finding set is complete. It reports what a defined review, run against an agreed scope with the accesses provided, was able to establish on the date it ran. Security work is a standing practice; the audit is the measurement that tells you where to start it.
The scope covers two layers in one engagement: what sits inside Drupal (roles, permissions, dependencies, code, sessions) and what sits around it (headers, secrets, edge protection, logging, environment separation). Scope lines are fixed at scope definition rather than implied, which means agreeing which sites, which languages, which environments, which sample URLs and journeys, and which accesses are needed. The budget buys a depth of review, and that depth is settled before work starts.
Findings arrive rated Very High, High, Medium or Informational, so remediation is sequenced by risk instead of triaged from a flat list. There is deliberately no Low level: a check that would sit there is either Medium or not worth running. Each recommendation carries an effort estimate, so the remediation can be budgeted and split between what you fix in-house and what you contract out.
The audit is a diagnosis, and a separate decision from the remediation. The findings are yours whoever implements them.
They've Trusted Metadrop
From manufacturing and specialty chemicals to humanitarian NGOs, professional associations and universities, organizations answerable to GDPR, WCAG and NIS2 across 50+ countries have relied on Metadrop for Drupal security, access-control and compliance work.
What clients say
Platform owners describe what changed once security exposure was measured instead of assumed.
When a Drupal security audit is the right next step
- A security incident has already happened, an intrusion, a defacement, a spam-relay abuse or a credential leak, and the question is what else is exposed.
- A compliance review went badly, or a first one is scheduled: an ENS audit, a NIS2 readiness review, a GDPR data-protection assessment, an internal IT-security review.
- An enterprise client sent a security questionnaire and the answers have to be evidenced rather than asserted.
- A tender annex asks for a security baseline. Public-sector and EU procurement commonly score documented security governance, and a rated audit is the artifact that answers it.
- The platform was inherited, taken over from a previous provider or built by people who have since left, with no documented security baseline and no record of what was hardened.
- An agency or systems integrator needs an independent read on a platform it has taken responsibility for, before committing to a remediation budget. The report goes to whoever commissions it.
- Core or a dependency has gone out of support, or the update backlog has grown past the point anyone is willing to estimate.
- The platform holds personal data at scale: supporter records, patient-adjacent content, member areas, application forms, where the exposure of that data is the risk being managed.
- An internal platform is in scope alongside the public site, an intranet or member area where the whole value is that the wrong person cannot see the wrong thing.
A home-appliance manufacturer's platform was taken over from a previous provider and audited across security, performance, functional and accessibility criteria. The findings scoped an urgent action plan, and a CDN and WAF deployment followed.
A security audit and a penetration test answer different questions
A security audit works from the inside with granted access. It reads the configuration, the role and permission model, the dependency tree, the custom code, the headers and the infrastructure setup, then reports what is wrong and what it would cost to fix. A penetration test works from the outside without that access: it attempts to exploit the platform the way an attacker would, and reports what was actually reachable.
The two are complementary. An audit finds classes of weakness a pentest may never reach, and a pentest proves reachability an audit can only infer.
Metadrop does not perform penetration testing in-house. Where a platform needs one, it is commissioned to a qualified third-party firm, an arrangement chosen for impartiality, since offensive testing carries more weight when it is not run by the team that built or maintains the platform. Metadrop's part is to scope the pentest, coordinate it, and turn its findings into prioritized, estimated remediation work alongside the audit's own findings, in one plan rather than two.
| Security audit | Penetration test | |
|---|---|---|
| The question it answers | What is misconfigured, outdated or over-permissioned on this platform? | What could an attacker actually reach from outside? |
| The access it needs | Granted access to configuration, code and infrastructure | No privileged access; it works the way an attacker would |
| What it produces | Rated findings with an effort estimate against each recommendation | Evidence of what was reachable, and how |
| Who performs it in a Metadrop engagement | Metadrop, in-house | A qualified third-party firm, scoped and coordinated by Metadrop |
| When it is the right first step | There is no documented security baseline, or a questionnaire, tender or compliance review is driving the review | The visible weaknesses have been fixed and reachability is the open question |
Automated vulnerability scanning is a third thing again: continuous, cheap and good at known-CVE detection. It runs as part of the audit's first pass, and the manual review that follows covers the judgement a scanner cannot make.
Access control, roles and permissions
The role and permission model is read as a whole rather than permission by permission: which roles exist, what each one can actually reach, and where a permission grants more than the role's name suggests. Least privilege is checked against reality, which surfaces administrator-equivalent roles held by people who do not need them, permissions accumulated over years of ad-hoc requests, and accounts still active for people who have left.
Node, field and file-level access is reviewed wherever the platform restricts content instead of publishing all of it: private file handling, unpublished-content visibility, and whether a direct URL bypasses the listing that was supposed to gate it. Multilingual and multisite estates get particular attention, because access rules that hold on one site or one language frequently do not hold on all of them. Authenticated and editorial areas are in scope too, since on an intranet, a member area or the back office the access model is the security model.
An international humanitarian NGO's platform uses condition-based role and permission controls that grant access dynamically according to defined conditions, rather than through static roles alone.
Core, module and dependency posture
Drupal core and contributed-module versions are checked against current security advisories and against their support status. An out-of-support core version is reported as a Very High finding, because nothing lower is worth fixing while it stands. The PHP and JavaScript dependency trees are both reviewed, not only the Drupal ones: Composer packages, transitively pulled libraries, and npm packages used in the build. Supply-chain exposure is a category in its own right, since a compromised package in a build toolchain reaches production without anyone touching application code.
Abandoned and unmaintained modules are flagged with the replacement or removal path, because an unmaintained module is a security decision and not only technical debt. The review covers update process, not just update state: whether patching is scheduled, who is accountable, whether staging exists to validate a security release, and how long a critical advisory currently takes to reach production. Metadrop's engineers have published on the npm supply-chain compromise and on why most Drupal platforms were not exposed by it, applying the same dependency-tree reasoning this check uses.
Input handling, file uploads and custom code
Custom and contributed code is reviewed against OWASP and Drupal's own security standards, working from the categories that keep appearing on platforms in production rather than a generic top-ten recital. The code-level findings that recur are unsafe file handling, header injection through unvalidated input, XML input processed without hardened parser settings, controllers exposing data with no access check, and raw output that bypasses Twig's escaping.
File-upload paths are checked end to end: allowed extensions, MIME validation, where files land, whether the web server will execute anything in that directory, and whether private files are served through Drupal's access layer as intended. Form and API surfaces, meaning webforms, REST and JSON:API endpoints and any custom route, are reviewed for authentication, authorization and rate limiting. Third-party integrations are treated as an attack surface: how credentials reach them, what data leaves, and what happens when the remote end returns something unexpected.
Sessions, authentication and account policy
Password and account policy is checked as configured rather than as assumed: length and complexity enforcement, flood control on failed logins, and whether user enumeration is possible through the login and password-reset flows. Multi-factor authentication coverage is read for privileged accounts, including whether it can be bypassed through an alternative login path. SSO and federated login, SAML or OIDC, are reviewed for role mapping, assertion validation, and what happens to access when someone is removed upstream.
Session handling covers cookie flags, session lifetime, and whether a session survives a privilege change or a password reset. Then there is the administrative surface itself: who can reach /admin and /user/login from where, and whether that reachability is a deliberate decision or an inherited default.
Security headers and browser-side policy
Response headers are read as they are actually served, per environment and per site, because the configured value and the delivered value are not always the same once a proxy or CDN sits in the path. The set checked includes Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options or frame-ancestors, Referrer-Policy and Permissions-Policy.
CSP is assessed as a working policy rather than a checkbox: whether it is in report-only or enforcing mode, how much is opened by unsafe-inline, and whether the report stream is being read by anyone. Header ownership is a finding in its own right, since headers set in three places at once (Drupal module, web server, CDN) is how a policy silently stops applying, so the audit reports where each header should live on this platform. Information disclosure through headers and error output is covered in the same pass: version banners, stack traces, and debug output left enabled on a production environment.
Metadrop's engineers have published on improving a Drupal site's HTTP headers with a public header analyzer, including the security-header set, using the same method as this check.
Secrets, credentials and key handling
Secrets in version control are searched for across history rather than only in the current checkout: API keys, private keys, database credentials and tokens committed at some point and never rotated. The review also establishes where secrets live at runtime, which may be environment variables, a secrets manager, or a settings file readable by more people than intended, and whether production credentials are reachable from a development environment.
Rotation practice is part of it: whether anything is ever rotated, and what the procedure is when someone with access leaves. So is service-account sprawl, meaning integration credentials with broader scope than the integration needs, and shared accounts nobody owns. Encrypted connectivity for administrative and deployment access is checked as well, including whether any path to production still runs unencrypted.
Bot traffic, abuse and edge protection
Bot and crawler load is measured before it is mitigated, because the share of origin work that is not human decides whether the finding is a security issue, a cost issue, or both. Edge protection is reviewed as configured: whether a WAF exists, which rule sets are enabled, whether rules are in blocking or logging mode, and whether anyone reads the log. Rate limiting and DDoS posture at the edge are read together with what the origin does when the edge is bypassed by a direct-IP request.
Spam and abuse controls on public forms, meaning CAPTCHA or equivalent, honeypot fields and submission rate limits, are checked for whether they still work rather than for whether they are installed. Credential-stuffing and enumeration exposure on login, registration and password-reset endpoints is examined in the same pass. AI-crawler and scraper traffic belongs in the picture too, since it has grown into a substantial share of origin load and is governed at the edge rather than in application code.
Metadrop has published analysis of bot traffic's impact on websites and how to mitigate it, which is the framing this check uses.
A gluten-free food manufacturer's platform completed a hardening pass after a security review: a Content-Security-Policy with reporting, consolidated security headers, an enterprise CAPTCHA mode, and private keys and credentials removed from the code repository. A multinational chemical group's platform, unstable and paying for malicious bot traffic, was moved behind CDN edge security with a web application firewall and DDoS mitigation, cutting bogus traffic peaks by roughly 90%. That engagement also delivered a GDPR cookie-compliance audit and rolled its action plan out across the group's sites.
Logging, monitoring and status signals
What is logged, where it goes and how long it is kept is the first question, because an incident nobody can reconstruct is an incident nobody can report, and reporting deadlines are contractual in public-sector and EU engagements. Database logging on a high-traffic platform is reviewed as an architecture decision, since a centralized log pipeline is the sustainable pattern once volume grows.
Alerting is read for which conditions actually raise an alert, who receives it, and whether anything fires before a visitor or a client reports the problem. Drupal's own Status Report is treated as an operational security signal, and the warnings ignored long enough to become invisible are frequently the audit's fastest findings. The audit trail for privileged actions closes the review: who changed a permission, published a node or altered a configuration, and whether that record survives a deployment.
Metadrop's engineers have published on managing Drupal Status Report requirements and on extending Drupal's log system, both routine parts of this review.
Environment separation, backups and tested restore
Development, staging and production separation is checked for isolation that holds in practice, not merely for existing on paper: shared databases, production data copied into a development environment without anonymization, and staging environments reachable and indexable from the public internet. Backup strategy covers what is backed up, how often, where it is stored, whether it is encrypted, and whether it is held somewhere an attacker with production access could not also reach.
Restore is checked as a practice rather than a setting: whether a restore has ever been performed, how long it took, and what the last drill actually proved. A backup nobody has restored is an assumption. Deployment pipeline access belongs to the same picture: who can deploy, whether deployments are reviewable and reversible, and whether security scanning runs in the pipeline before code reaches production.
Hosting-tier and infrastructure posture is assessed, not procured. Where the finding is that the platform has outgrown its plan or its provider, see Drupal hosting.
Mapping findings to ENS, NIS2, GDPR and ISO 27001
Technical findings on their own do not answer a compliance question, so the audit can also deliver a gap analysis that maps each finding to the requirement it bears on, in the framework you are accountable to. What that gives you is the technical translation of a regulatory requirement: which control the platform does not currently satisfy, and what work would close it. It stops short of a legal opinion, a certification or a statement that the platform is compliant, because that determination belongs to your own auditor or counsel.
GDPR findings are the ones bearing on personal-data exposure through access control, private-file handling, log retention, third-party data flows and consent implementation. A platform leaking personal data can increase compliance risk for organizations subject to these requirements, and the determination of what that means for a given organization stays with its own counsel.
NIS2 raises expectations around risk management, incident handling and supply-chain security for entities in scope, and the audit's dependency, logging and incident-readiness findings are the ones that map onto it. The deliverable is framed as prepared for NIS2 requirements, never as compliance with them, and whether NIS2 applies to your organization is a scoping question for your legal or compliance function.
ISO 27001 and 27002 findings can be expressed against the control families a certified or certifying organization is already working with, so the audit output slots into an existing ISMS instead of sitting beside it. OWASP categories group the code and configuration findings, which is the vocabulary most enterprise security teams and questionnaires already use.
ENS is a qualified segment rather than the default offer. A formal IT Security Plan with a full ENS control-mapping matrix is a public-sector and EU-tender deliverable, scoped when the contract requires it. For a commercial buyer the audit is lighter: findings, prioritized remediation and a gap read, without a control-mapping matrix.
Metadrop audits from an externally certified baseline. That baseline is an externally audited ENS certification (Esquema Nacional de Seguridad, Categoría Media, under RD 311/2022) covering more than 64 distinct security measures across risk management, access control and incident response, held inside an ISO 9001 quality-management system. ENS is deliberately aligned with GDPR, the NIS and NIS2 directives, ISO 27001/27002 and ENISA guidance. This is Metadrop's own certification and process maturity, so it is what grounds the audit rather than a claim about what any client platform will achieve. Metadrop's internal risk cycle of identify, assess, mitigate and monitor mirrors the EU Commission's IT Security Risk Management (ITSRM) methodology, and a team member holds the ITSRM certification from ENISA, the EU Agency for Cybersecurity.
Risk is presented so a non-technical decision-maker can act on it. The findings deck carries the technical detail, while the presentation states what each Very High and High finding means in business terms, because the people who approve the remediation budget will not read the code.
How the audit runs
The engagement runs in five stages, the last two of them contracted separately.
Scope definition
Agree the sites, environments, sample URLs and journeys, the depth per check area, and the accesses and tooling needed.Timeboxed execution
An automated pass runs every check that has been automated, and the reviewer's time then goes to what automation cannot decide, meaning judgement, context and manual sampling. The baseline measurements every later comparison depends on are captured here.Presentation
Walk the findings and the prioritized recommendations with the technical and the non-technical members of the buying group, in language both can act on.Remediation, only when contracted
As a project, or as evolutive work inside a Drupal maintenance contract, following a documented triage-to-verification workflow of logging and triaging each finding, prioritizing with you, patching and testing on staging, deploying and verifying, then reporting what was closed.
Consultancy loop, only when contracted
Re-measure the agreed indicators against the audit's baseline at an agreed cadence. Every indicator tracked traces back to a check that established its baseline.
What you receive
The deliverable is a findings deck with each finding rated and tied to its evidence, a prioritized recommendation list carrying an effort estimate per item so remediation can be budgeted, and, where the gap analysis is in scope, the mapping of findings to the framework you answer to.
| Criticality | What the rating means |
|---|---|
| Very High | A blocker; while it stands, the audit's goal cannot be met. |
| High | Significant impact, fix in the same round of work. |
| Medium | Worth fixing, batch it. |
| Informational | Records a state or a deliberate decision; reported, never actioned. |
No Low level exists, by design.
How your platform is handled during the review: read-only access wherever read-only is enough, credentials passed through a secrets manager rather than email, any test that changes configuration run on a non-production environment, and findings shared through an access-controlled channel, since a findings list is itself sensitive material. Metadrop's own baseline applies to the engagement as well: multi-factor authentication on privileged access, encrypted devices, least-privilege access to client systems, EU data residency, and a documented incident-response process with a defined notification commitment.
Drupal versions covered run from Drupal 7 to Drupal 11. On an out-of-support version, the audit reports the exposure and the upgrade path together, because patching stops being available before the risk does. Clients already on a maintenance contract get an automated check pass at no extra cost, monthly, with the highlights worth acting on turned into tasks; a contracted audit is the in-depth, manually reviewed version of it.
Across maintained platforms, the standing controls Metadrop puts in place and keeps in place include web application firewalls, bot and spam mitigation, password-policy enforcement, node-level access control, secrets held in a key manager, security headers and content-security policies, which is the practice behind the audit's recommendations. Behind the engagement sit Metadrop's standing credentials: 15+ years specializing in Drupal, Drupal Silver Certified Partner status, ENS certification, and a GDPR, WCAG and NIS2 compliance track record on platforms serving 50+ countries and 30+ languages.
Security is one topic in the audit family and can be combined into one engagement with accessibility, technical SEO, UX/UI or GEO & AEO: one scope, one presentation, one prioritized list.
Frequently asked questions about Drupal security audits
What is a Drupal security audit?
A Drupal security audit is a point-in-time review of a Drupal platform against known classes of security risk: access control and permissions, core and dependency posture, custom code, security headers, secrets handling, logging, and edge protection. It is delivered as rated findings with a prioritized remediation plan. It runs with granted access to the platform, its configuration and its infrastructure, which is what lets it report causes rather than symptoms. It is also timeboxed, in that the agreed budget sets the depth of review and the sample, both fixed before work starts.
What is the difference between a security audit and a penetration test?
A security audit reviews the platform from the inside with granted access, while a penetration test attacks it from the outside without any. The audit reports what is misconfigured, outdated or over-permissioned; the pentest reports what an attacker was actually able to reach. They answer different questions and are usually bought in sequence, the audit first, because fixing what is already visible costs less than discovering it under attack simulation. In a Metadrop engagement the audit is performed in-house, and any penetration test is commissioned to a qualified third-party firm for impartiality, with Metadrop scoping it, coordinating it and folding its findings into the same prioritized remediation plan.
Will a Drupal security audit find every vulnerability on our platform?
A Drupal security audit cannot claim a complete finding set, and this one does not. It reports what a defined review, against an agreed scope and sample, was able to establish on the date it ran. What it is designed to do is find the exposure with the highest likelihood and impact first, rate it, and put an effort estimate against fixing it, so the remediation budget goes where the risk is. The honest framing is that the audit lowers unknown exposure and gives you a baseline, and that keeping it low is a standing practice of patching, monitoring and review rather than a one-off purchase.
How often should a Drupal platform be security-audited?
A full security audit every 6 to 12 months is the usual cadence for a business-critical Drupal platform, with an additional one triggered by an event rather than by the calendar. The events that should trigger one are a major version upgrade, a migration or replatform, a provider handover, a significant new integration, a security incident, and a compliance review or tender submission. Between audits, the work that matters is continuous rather than periodic: dependency and vulnerability monitoring, prompt security patching, and edge-log review.
How long does a Drupal security audit take, and does it touch the live site?
A Drupal security audit is timeboxed to the agreed budget, which is what sets its duration: a focused scope on a single site typically runs in days, a large multisite or multilingual estate in weeks. Review is non-intrusive by design, with read-only access wherever read-only suffices, an agreed URL and journey sample on production, and anything that changes configuration run on a non-production environment. What shortens it most is having the accesses, the environments and the sample list ready at scope definition; waiting on credentials is the single most common delay.
What does a Drupal security audit cost?
A Drupal security audit is quoted per engagement, because the timebox is the product: the budget sets the depth of review, and the scope is agreed before any work starts. The cost drivers are the number of sites, languages and environments, the size and age of the custom codebase, how many integrations are in scope, whether the infrastructure and edge layers are included, and whether a compliance gap analysis is part of the deliverable. Rates are not published. A scoping conversation is what produces a figure, and it is the same conversation that fixes the scope, so the number and what it buys arrive together.
Does NIS2 apply to our website?
Whether NIS2 applies is a question about your organization, not about your website. The directive scopes entities by sector, size and criticality, and its transposition into national law differs by member state, so that determination belongs with your legal or compliance function rather than with a technical supplier. Where an organization is in scope, the obligations that reach a public-facing platform concern risk management, incident detection and reporting, and supply-chain security, which is where an audit's dependency, logging and incident-readiness findings become useful evidence. Metadrop's contribution is the technical translation: which controls the platform does not currently satisfy and what work would close the gap, expressed as findings prepared for NIS2 requirements rather than as a compliance statement.
Our hosting provider says it handles security, so do we still need an audit?
Hosting security and application security cover different ground. A provider secures the infrastructure it operates, patching the operating system, the network perimeter and the platform tier, and typically does not review your role and permission model, your contributed-module versions, your custom code, your security headers or your form abuse controls. The gaps this most often surfaces are bot and scraper traffic reaching the origin because no edge rules were configured for this site, a disclosed module vulnerability with no patch scheduled, and secrets committed to the repository, none of which a hosting tier detects on your behalf. The practical division is best settled in writing: the audit reports which findings belong to the platform, which belong to the provider, and which belong to whoever maintains the code. See Drupal hosting for where the infrastructure boundary sits.