Organizations moving off a managed Drupal platform frequently discover, during the first audit after the move, that the platform's controls were the controls. The web application firewall, the transport security, some access control and a degree of hardening were included, invisible, and are now absent.
This is what has to exist instead. It is deliberately a control list rather than a product list, because the products vary and the obligations do not.
Edge
The first layer a request meets, and the one that should absorb most hostile traffic.
- Web application firewall. Rules tuned to the application rather than accepted as a default. A ruleset nobody has tuned either blocks legitimate editorial traffic or permits everything.
- Denial of service protection. Volumetric absorption at the edge, and rate limiting on the paths that cost most to serve, which for Drupal usually means search and authenticated routes.
- TLS everywhere, including between the edge and the origin. The internal hop is regularly left plaintext on the reasoning that it is a private network.
- Cache correctness. A caching rule that stores an authenticated response in a shared cache is a data exposure wearing a performance label. Drupal's cache metadata exists to prevent this; the edge has to respect it.
Identity and access
Two distinct populations, and conflating them causes trouble.
People who administer Drupal. Authenticate against the organization's directory with single sign on and multi-factor authentication, rather than against a second set of credentials nobody rotates. Roles reflect what people actually do; the administrator role is granted rarely and reviewed.
Machines that reach infrastructure. The pipeline, the application, the monitoring agents. Each with its own identity, scoped per environment, so the identity that deploys to development cannot reach production. Prefer federated identity over long lived keys: a static credential in a pipeline has no expiry and no owner, and it outlives whoever created it.
The test worth applying: if one credential can reach every site's storage, the isolation shown in the architecture diagram is not present in the account.
Secrets
A managed secret store, referenced rather than copied. The pipeline holds a reference; it does not hold the secret. That is what makes rotation possible without editing pipelines.
One Drupal specific caution and one Infrastructure as Code caution.
Drupal's settings file holds a database credential and a hash salt. It belongs outside the repository, injected at deploy, and treated as a secret rather than as configuration.
HashiCorp is explicit that Terraform must store state about your workspace's managed infrastructure and configuration, and that mishandling it can result in exposure of secrets stored in the state file. State is a sensitive asset with a custody problem, and where it lives and who can read it are decisions to take before the first apply. See Terraform and Infrastructure as Code for Drupal.
Network segmentation
The application layer reachable from the edge and nowhere else. The database reachable from the application layer and nowhere else. Administrative access through a controlled path rather than an address allowance somebody added during an incident.
On an estate, the sharing decision is a security decision. If forty sites share one database service, a compromise of one application instance is a question about what that instance's credential can reach. Scoping credentials per site is what keeps a shared service from becoming a shared blast radius.
Platform hardening
The unglamorous layer, and the one that decays without an owner.
- Operating system, PHP, database engine and base images patched on a cadence, with coverage reported rather than assumed.
- Instances built from an image rather than configured in place, so that patching is a redeploy rather than an intervention.
- File permissions such that the web server cannot write to the codebase. Drupal needs to write to its files directory and to nothing else.
- Administrative interfaces not reachable from the open internet where the organization's arrangement permits that.
Patch coverage is the number worth reporting. Without it, patching is a matter of belief.
The application supply chain
Most of the code in a Drupal site was written by somebody else, which makes the dependency tree the largest single attack surface and the most tractable one.
Composer describes itself as a tool for dependency management in PHP, and the tree it resolves is what has to be watched. OWASP describes Dependency-Check as a Software Composition Analysis tool suite that identifies project dependencies and checks whether any have known, publicly disclosed vulnerabilities, and running it on a schedule as well as on commit is what catches an advisory published after your last release.
Two artifacts make the response fast rather than exploratory. A software bill of materials, for which CycloneDX describes itself as a modular and extensible framework designed to represent a broad range of supply chain information, answers whether you are affected. Build provenance, for which SLSA is organized into a series of levels that provide increasing supply chain security guarantees, answers how the artifact was produced.
Where these sit in delivery is covered in building a Drupal DevSecOps pipeline in Azure DevOps.
Logging and detection
Application, infrastructure and security events collected where they can be correlated, retained for a period somebody chose, and routed to whatever the organization uses for security monitoring.
Drupal's default of logging to its own database is convenient and wrong for a platform: a database problem removes the record of the database problem. Ship logs off the instance.
Worth capturing specifically: authentication attempts including failures, permission and role changes, configuration changes, and administrative actions. Those four are what an investigation actually needs, and they are frequently the four not collected.
Log stores hold personal data and carry the obligations that implies, including a retention decision made for a reason.
What OWASP is and is not for
The OWASP Top 10 describes itself as a standard awareness document for developers and web application security. It is an excellent orientation and it is not a control framework, not a certification, and not a checklist an organization can be assessed against.
Used well it prompts the right questions during design review. Used badly it becomes a compliance artifact, and a page claiming a site is compliant with an awareness document is claiming something that does not exist.
Drupal specific exposures worth designing for
Beyond the generic web controls, a handful of exposures recur on Drupal estates specifically. None is exotic; all are commonly found during an assessment.
- Private files served directly. Drupal expects private files to be delivered by the application so that access can be checked. If the web server or an object store is serving that directory directly, the permission model is bypassed and nothing errors. This is the most frequent real finding on a migrated estate, because the arrangement that enforced it did not survive the move.
- The update path left reachable. Administrative routes that perform updates should not be reachable from the open internet on a platform where deployment is automated. If releases go through a pipeline, the interactive path is an unnecessary door.
- Overly broad roles. Estates accumulate a role that was created for one task and now carries permissions nobody has reviewed. The permission that allows arbitrary PHP or arbitrary markup is effectively administrative, whatever the role is called.
- Modules enabled and unused. Every enabled module is code that runs. An estate that has never audited what is enabled is carrying attack surface for functionality nobody uses, and disabling is cheaper than patching.
- Editorial input treated as trusted. Text formats that permit scripting, granted to roles broader than intended, turn a content account into something closer to an application account.
- The forgotten environment. A staging site with production data, weaker access and no monitoring, reachable from the internet because somebody needed to show a client. This is where estates leak, and it is why environment expiry in self-service platform operations is a security control rather than a cost control.
The first and last of those share a property worth noting: both are invisible to a scan of the production application, and both are found by asking how the platform is arranged rather than by testing the site.
What can and cannot be claimed
A short section because the language here matters and is regularly overstated.
Aligning a platform with the practices in a framework is not the same as being assessed against one. NIST recommends in SP 800-218 a core set of high-level secure software development practices that can be integrated into each SDLC implementation, and NIST certifies, approves and endorses nobody. The honest verbs are informed by, aligned with, maps to and draws on.
Similarly, a data center provider's independent examination is a statement about that provider's facility and its controls, not about a tenant's application. Running in a facility that has been examined is a fact worth stating precisely and worth not stretching.
Where LABUSA fits
LABUSA's technical capabilities span private infrastructure, public cloud, cybersecurity, enterprise architecture and AI implementation. It operates hybrid infrastructure combining privately hosted infrastructure with AWS, AWS GovCloud (US) and Microsoft Azure services, and runs privately hosted infrastructure from a carrier-neutral data center facility in the Houston area.
Assessment questions
- Which of these controls was the previous platform providing, and which now has an owner?
- Can one credential reach more than one site's data?
- Are authentication failures and permission changes logged anywhere queryable?
- How long between a published advisory and knowing whether you are affected?
- Who reviews administrator accounts, and when did they last do it?
Question one is the migration's real security scope. Question four is the one whose answer is usually days and is expected to be minutes.
Security is a layer of the reference architecture and a workstream inside secure Drupal cloud modernization. If the answer to question one is uncertain, that is the assessment worth running first.
Sources
The external statements on this page are quoted from the following, each re-read on 10 September 2026.
- Composer, Introduction, Composer documentation
- HashiCorp, State, Terraform language documentation
- OWASP, OWASP Top 10
- OWASP, OWASP Dependency-Check
- OWASP CycloneDX, Specification Overview
- SLSA, Security levels, SLSA specification v1.0
- NIST, Secure Software Development Framework (SSDF) Version 1.1, SP 800-218