Drupal Steward web application firewall

What the Drupal Steward web application firewall does and when teams need it

A Drupal owner who must answer a critical core advisory before the patch can be tested and released needs a way to reduce exposure in the meantime. A web application firewall sits in front of the website and inspects incoming HTTP requests, blocking or filtering those that match rules for known attack patterns. The Drupal Steward service is offered as a managed layer of this kind, with virtual patching intended to cover a highly critical vulnerability until the site can take the fixed release. Before relying on it, confirm with the provider which vulnerability classes and specific advisories its rules cover, where it is deployed (at the DNS, CDN, load balancer or web server), how rules are tuned and rolled back, and what it does to legitimate traffic. No product documentation was supplied for this page, so none of these details should be assumed.

Teams most often evaluate a service like this in three situations. The first is a regulated site where a change window is set by policy and a security patch cannot reach production as quickly as the advisory timeline demands. The second is a site with slow change control, where testing across custom modules, contributed projects and the theme takes longer than the exposure window allows. The third is a site still running an unsupported version, such as Drupal 7 after its security support ended on January 5, 2025, while a migration to a supported release is planned. In that last case, the Drupal Association's Extended Security Support Provider Program lists certified vendors for sites that cannot migrate yet, and a firewall layer is a separate decision that should be assessed alongside that option. Ask the provider how it handles sites that run unsupported core versions, since the rule set may not match the code paths in those releases.

A web application firewall is a compensating control, not a substitute for the update. It does not fix the vulnerable code, it does not cover every path an attacker can reach, and it does not protect a site once a vulnerability is publicly described and bypass techniques appear. The security release from the Drupal Security Team remains the fix, and the firewall only buys time to apply it safely. Plan the update process so the patch is applied in the next security window, typically the third Wednesday of the month according to the Drupal core release schedule, and record the firewall as a temporary control with an owner and a removal date. Any compliance evidence should describe it as an interim measure, and the assessor should be told it was used.

Configuration decisions and when each fits

This table compares the decisions a team makes before enabling Drupal Steward, with the situations where each choice fits and the questions to put to the provider. Read each row as a decision to settle in writing before go-live, since several of them change who answers when a rule blocks a legitimate editor or admin request. The main takeaway is that inspection point, rule mode and exception ownership should be agreed before the service is switched on.

Decision	When it fits	What to confirm with the provider
Where traffic is inspected	Edge or CDN inspection fits when you already front the site with a CDN and want blocked requests to stop before they reach your origin. Web server side inspection fits when traffic reaches the origin directly, or when you need the decision to sit close to the application.	Which request paths and headers are visible at each point, whether TLS is terminated before inspection, and how origin IP addresses are protected if traffic bypasses the edge.
Monitor mode or block mode first	Monitor mode fits a first deployment on a busy or heavily customized site, where you need to learn which legitimate editor or admin requests look suspicious. Block mode fits once the rule set has been tuned against your real traffic and the exception path is working.	Whether rules can be set per rule or per path, how long monitor mode typically runs in your environment, and what evidence the provider gives you before you switch a rule to block.
Exception requests for editor and admin forms	Exceptions are needed when content editors use rich text, file upload or bulk operations that resemble attack traffic. Assign one owner for the exception queue, usually the platform or security lead, so that a block on a publishing task is resolved quickly and recorded.	How an exception is requested and approved, the scope of an exception (path, rule, user role or IP range), and whether exceptions expire automatically or need manual removal.
Log feed into the SIEM	A SIEM feed fits organizations that already correlate web events with identity and endpoint data and need blocked and allowed requests in the same investigation workflow. Without a feed, blocked events stay in the provider console and are harder to review during an incident.	Which log fields are supplied, the delivery method and format, retention on the provider side, and whether logs include the rule identifier needed to explain a block.
Retiring virtual patch rules after a core update	Retirement fits a planned routine: once the core or contributed update is deployed and verified on the site, the matching virtual patch is removed so that rules do not accumulate. Keep a record of which advisory each rule covered so the removal is traceable.	Who approves removal, how the provider maps each rule to a Drupal advisory, and how you verify the patched version is live before the rule is disabled.
Coverage of contributed modules	Confirm coverage early if your site depends on contributed modules that carry most custom functionality, since a rule written for core may not match module specific routes.	Whether the provider covers the specific contributed modules you run, and how new modules are added to the protected set.

What virtual patching buys time for, and what it does not

Virtual patching is a temporary control placed in front of a Drupal site while its code stays unchanged. The four cards below cover what a rule can block, how long it can hold, where it fails, and what to confirm with the provider before relying on it.

Blocking a known exploit path

A virtual patch is a rule at the request layer that matches a known exploit path for a published core vulnerability and blocks matching traffic before it reaches Drupal. The site keeps its current code, so the rule is a compensating control rather than a code change. For example, an illustrative rule might drop requests to one vulnerable route that carry a particular malformed parameter. Ask which advisory each rule covers and which request pattern it matches.

The window before the security release

Drupal security releases come out on the third Wednesday of the month, according to the core release schedule. A highly critical advisory can be public before the team has tested the fixed release in staging and scheduled it for production. Virtual patching covers that gap, but it only holds the site until the update is deployed. Plan the Wednesday update as the permanent fix and record the date the temporary rule was enabled.

Where the exploit takes another path

A rule matches a specific request shape. An attacker who reaches the same flaw through a different route, a different encoding or a different payload may pass the rule untouched. Rules can also block legitimate editor or integration traffic that happens to match. Test each rule against known-good requests in staging, including content editing, login and API calls the site depends on, and review blocked-request logs after enabling it.

Confirming advisory coverage and speed

Before relying on Steward for an advisory, confirm which advisories have rules, whether contributed modules as well as core are covered, and how many days passed between the public advisory and the rule going live. The Drupal Security Team publishes advisories with CVE identifiers and risk scores, so match each Steward rule to a specific advisory identifier. Write these answers into the site's patch register so the internal patch deadline is measured from the advisory, not from the provider's report.

Why Steward does not replace core and contributed updates

A firewall rule addresses request patterns, not the vulnerable code. Steward can block traffic that matches the attack signatures it recognizes, which buys time while a fix is prepared. The vulnerable code stays in place, though. Any request shaped differently from the known pattern can still reach the flaw, and the rule set does not change what Drupal core or a contributed module does once a request is processed. The Drupal Security Team publishes advisories and uses the third Wednesday of the month for security releases, while bugfix releases come out on the first Wednesday. Your team should treat the Wednesday security window as the date the real fix becomes available, and plan to apply it on that cycle rather than waiting for the firewall to cover the gap.

Steward's coverage is also narrower for contributed modules. A generic rule set is written around core behavior and common module patterns, so a vulnerability in a less common contributed project may not be reached at all. Check each advisory against your installed projects, and ask the provider which projects and advisory types its rules are written to cover before relying on virtual patching for them. Unsupported major versions present a sharper limit. Drupal 7 security support ended on January 5, 2025, and a firewall cannot restore support for code that no longer receives fixes. The lasting answer is migration to a supported version, and the Drupal 7 end of life partners page lists the extended support vendors that some sites use while they plan that move.

Keep a documented update process even with Steward in place. Record every installed core and contributed project with its version, subscribe to security advisories, and set an internal deadline for applying security releases after each Wednesday window. Test the update in a staging environment with a copy of production configuration, run your regression checks, then deploy and confirm that the firewall rules still match the updated code. Keep a rollback plan and a log of when each advisory was received, patched and verified. Confirm with your provider how rules are changed after a patch is applied, who approves those changes, and how quickly rules are retired once the code is fixed.

How the firewall decision differs by site situation

A Drupal 11 site on a regular update cycle is where Steward adds the least that routine maintenance does not already cover. Bugfix releases arrive on the first Wednesday of each month and security releases on the third Wednesday, so most advisories close within a normal patch rhythm. Steward's value here is a buffer for the gap between a highly critical core advisory and the moment your team can deploy the fix.

Patch window gap: Measure how long your team takes to move a security release into production, and compare that with your internal deadline for highly critical issues.
Scope of virtual patching: Confirm with the vendor whether virtual patches cover contributed modules or only core, since much custom and contributed code sits outside core.
Runtime versions: Drupal 11 requires PHP 8.3 or later. The firewall does not change the PHP version, so confirm your web tier meets that requirement.
Legitimate traffic: Test JSON:API calls, webform submissions and login flows through the firewall in staging so editors and integrations are not blocked.

Before enabling blocking, record the deadline your policy sets for highly critical advisories and confirm the rule set passes your staging tests.

How to set up Steward alongside your update process

This sequence connects Drupal Steward to the update process you already run, so virtual patches cover the gap between a critical advisory and a tested core or contributed update, and do not become a permanent substitute for it.

Confirm scope and pricing in writing
Before any configuration, agree in writing with the provider which sites, environments and hostnames Steward covers, how virtual patches are issued and who approves them, what the service does and does not protect against, and how fees and renewals are structured. Ask for the terms that govern response when a highly critical core vulnerability is announced. Your procurement and security leads should sign off on this document. The step is complete when the scope, responsibilities and fee basis are on file and match what the provider will deliver.
Inventory public hostnames, forms and API routes
Your team lists every public hostname, anonymous or authenticated form, search endpoint, file upload path, JSON:API or REST route and admin path that the firewall will see. Include routes from custom modules and any headless front ends that call Drupal. Compare this list with the web server and CDN configuration so nothing reaches Drupal around the firewall. The step is complete when the inventory is reviewed by the site owner and the provider has confirmed which entries are in scope.
Deploy in monitor mode and review false positives
Deploy Steward in a mode that logs matches without blocking, then run representative traffic through editor, admin and checkout or registration flows. Record each match that would have been blocked and decide whether it is a genuine attack or a legitimate request, such as a rich text submission or a bulk content import. Ask the provider to document how rules are tuned for those paths. The step is complete when false positives on admin and editor paths are either tuned or accepted in writing, and blocking mode has an agreed switch-over date.
Agree exception handling and a change record
Define who may request an exception to a rule, who approves it, how long it stays in force, and where it is recorded. Each exception should name the route, the rule, the reason and the review owner. Keep these changes in the same change management system your team uses for code and configuration, so auditors and incident responders can trace what was blocked and why. The step is complete when a sample exception has been requested, approved and recorded end to end.
Connect Steward logs to your monitoring
Send Steward's blocked and allowed request logs to the same platform that collects Drupal, web server and database logs, so one investigation can follow a request from the edge into Drupal. Set alerts for spikes in blocked requests on login, registration and admin paths. Confirm with the provider which log fields are available and how long they are retained on their side. The step is complete when a test event appears in your monitoring tool and an alert fires as expected.
Define the virtual patch trigger and replacement deadline
Write down the condition that starts a virtual patch, such as a highly critical core advisory that has no fixed release yet, and the internal deadline for replacing that patch with the official core or contributed update. Tie the trigger to Drupal Security Team advisories and the scheduled security release window, and confirm with the provider how quickly they can deploy a rule after an advisory. Test the update path on staging in advance. The step is complete when the trigger, the owner and the replacement deadline are approved and a rehearsal has been run.
Schedule a periodic review of rules and updates
Set a recurring review, at a cadence your team chooses, that checks every active virtual patch, exception and false positive against the current Drupal release status. Remove any rule whose underlying vulnerability has been fixed in a core or contributed update already applied. Confirm that the site is on a supported Drupal version and PHP version, since a firewall rule cannot protect a release that no longer receives security coverage. The step is complete when the review record shows each active rule has an owner and either an expiry or a planned update.

Security and operational risks to plan for

A firewall in front of Drupal adds its own failure modes, from blocked editors to logs that hold personal data. Each card names one risk to plan for and the control that keeps it manageable, and the provider's configuration should confirm how each one is handled.

False positives block legitimate work

A rule that stops a request pattern can also stop an editor saving rich text, a form submission containing code-like text, or a file upload. Drupal sites produce these patterns often, because editors paste markup and forms accept free text. Start in a mode that logs matches without blocking, review those matches with the people who use the site, and keep a documented exception process with a named owner, a reason and an expiry date for each allowance. Ask the provider whether exceptions can be scoped to a single path or form.

Origin reachable around the firewall

If the Drupal origin server accepts traffic directly from the internet, an attacker can send requests to it without passing through the firewall, and the protection does not apply to those requests. Before go-live, confirm the network path: the origin should accept web traffic only from the addresses the provider forwards from, and direct requests to the server address should fail. Repeat this test from outside your network after every change to DNS, load balancers or firewall rules, and keep the results as evidence.

Rules that go stale

Rules are tuned against the site as it existed at the time. A new contributed module, a changed form or a new endpoint can fall outside them, and a core update can change the request shape the rules expect. Drupal core security releases arrive on the third Wednesday of the month and bugfix releases on the first Wednesday, so schedule rule review around those dates. After each release, check the logs for new blocks and confirm the rules still match the endpoints in use.

Logs holding personal data

Firewall logs can record client addresses, request paths and, depending on configuration, form field values or session identifiers, which may be personal data under your privacy obligations. Decide before go-live how long logs are kept, who can read them and whether request bodies are stored at all. Ask the provider which fields are captured, whether they can be redacted and where the logs are held. Limit access to the security team, review that access periodically, and delete logs when the retention period ends.

Admin paths need their own restriction

The firewall filters requests, but it should not be the only control between the internet and administrative functions. Paths such as /user/login and /admin should be limited by network address, VPN or single sign-on with multi-factor authentication, and Drupal's flood control and password settings should stay enabled. Check that administrative paths are denied from outside the approved network, and retest after every configuration change.

Questions buyers ask about Steward cost, effort and fit

What drives the cost of Steward, and who pays for what?

Steward cost comes from two sources: the subscription for the service itself, and the testing effort your team or a partner spends making rules work on your site. The subscription is a recurring charge set by the service provider, so ask for its scope, term and renewal terms in writing. Testing effort is heaviest at enablement but recurs whenever rules change, a new module is installed or a Drupal release changes page markup. Costs rise with the number of sites, custom routes and forms, required exceptions and environments that must be tested before production. Ask for any quote to separate the subscription, enablement work and ongoing rule maintenance, and to state who performs each one. DeployOpen does not publish prices. A quote follows from a written scope.

How long does it take to switch Steward on for a Drupal site?

Enablement time depends mainly on how well your routes and traffic are understood before rules go live. A site with a documented list of public pages, authenticated editor and admin areas, custom forms and API endpoints tends to move faster than one that must be mapped during the work. Other drivers include the number of environments, whether rules run in a monitoring mode before blocking starts, the number of false positives found in staging and how quickly the named owner can approve exceptions. Ask the provider for the expected duration and the testing steps in writing, along with the assumptions behind them. Any duration you receive should be tied to the scope you agree, so that changes to scope are priced and scheduled openly.

What does the internal team need to provide before enabling Steward?

Your team should prepare four inputs before enablement:

An inventory of routes, including public pages, search, user and admin paths, custom modules and file upload endpoints.
A staging environment close enough to production to test blocking rules and real form submissions.
A named owner who can approve exceptions, decide whether a blocked request is legitimate and sign off on rule changes.
Access to web server and CDN logs so blocked and allowed requests can be reviewed.

Illustrative example: a site with a custom donation form and a file upload endpoint needs both paths listed and tested before blocking is enabled, or legitimate donors may be stopped. Confirm with the provider which log formats and access levels it requires.

Can our own team run Steward without outside help?

A team with web operations and Drupal experience can run Steward, but the work is ongoing and does not end at setup. Ownership includes reviewing blocked requests, adjusting exceptions after each Drupal or contributed module release and confirming that rules still match the site. Outside help is useful for the first configuration, for designing test cases or for reviewing rules after a major change. Ask the provider whether it offers documentation, training or support tiers, and what each covers. Whether your team or a partner should own upkeep depends on how many sites you run, whether someone has time for regular log review and how quickly you need expert changes during an incident. DeployOpen offers ongoing support and retainers if you prefer to outsource that upkeep.

Does a web application firewall replace the Drupal security update process?

No. A web application firewall filters traffic in front of the site and can reduce exposure for a period, but it does not fix the vulnerable code. The Drupal Security Team publishes advisories for core and contributed projects, and security releases come out on the third Wednesday of the month, according to the core release schedule. Steward's virtual patching is a compensating control that buys time while you schedule the update, so your internal patch deadline still applies. Keep your update process, including staging tests and rollback plans. Confirm in writing which advisories the service covers, how quickly rules are published and how long they stay in place.

What happens to protection if our Drupal site stays on an unsupported version?

Protection weakens, and the site stops receiving upstream fixes. Drupal 7 security support ended on January 5, 2025, according to Drupal.org, and Drupal 10 reaches end of life on December 9, 2026, according to the Drupal core release schedule. A firewall rule set cannot repair unsupported core code for every flaw that may be found later. Where a site cannot migrate yet, the Drupal Association's Extended Security Support Provider Program lists HeroDevs and Tag1 Consulting as certified vendors. Ask the Steward provider which Drupal versions it covers, whether coverage changes at end of life and what happens to a rule that depends on a component that is later removed. Migration planning should start before support ends.

Limits to confirm with the provider before you buy

Drupal Steward is a bought service, so its boundaries are set by the provider's written terms rather than by the platform itself. DeployOpen does not set these terms, and the provider's written documentation governs. Use the six points below to build your question list before you sign.

Advisory coverage and lag

Ask which Drupal core and contributed advisories the service covers, and how far behind public disclosure virtual patches go live. Compare that lag with your internal patch deadlines, since a late rule is no protection for a highly critical advisory that is already being exploited. Ask whether coverage is listed per advisory and how you are told when a rule is retired after the real fix ships.

Encrypted traffic inspection

Confirm whether the service decrypts TLS at its edge or needs your origin to change. If inspection requires terminating TLS at the provider, ask where private keys are held, who can access them, and how certificate rotation works. Also ask whether traffic is inspected before or after your CDN, because that changes which client IP addresses the Drupal logs record.

Hosting and CDN arrangements

Drupal runs on Apache, Nginx and other web servers with MariaDB, MySQL, PostgreSQL or SQLite, so confirm that your web server and any reverse proxy or CDN in front of Drupal are supported. Ask whether the service works with your DNS setup, how origin lockdown is enforced, and whether it supports your container or Kubernetes layout if you run one.

False positive handling

Ask how a legitimate editor, form submission or API call that gets blocked is reported, who can add an exception, and how long a fix takes. Check whether exceptions are scoped to a path, a rule or an IP range, and whether they are reviewed when Drupal or a contributed module changes. Editors on admin paths are the usual source of these reports.

Data residency and log handling

Ask where request logs are stored, which countries they pass through, how long they are kept and who at the provider can read them. Confirm whether logs contain form data, session cookies or personal data, and whether you can export or delete them. Regulated organizations usually need this answer before the technical rollout.

Renewal, exit and support terms

Confirm renewal terms, notice periods, what happens to rules and logs at exit, and the support hours and escalation path for an active attack. Ask how the service behaves if your subscription lapses, because the origin may then be exposed to the advisories it was covering. Note that the service is not a substitute for updates on the Drupal release schedule.

How DeployOpen works on this

DeployOpen plans, implements, hardens and documents self-hosted Drupal sites inside the client's own infrastructure. For Drupal Steward web application firewall, we scope the protection layer against the site's update process, so that virtual patching is treated as a bridge to a core or contributed update rather than a substitute for one.

How we scope

We confirm which Drupal version, PHP version and web server or CDN the site runs before agreeing what Steward would cover.
We record which paths, admin routes and custom modules fall inside the protection perimeter and which stay outside it.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any configuration work begins.

How we build

We review the site's exposed endpoints and inventory contributed modules so the rule set reflects what is actually deployed.
We stage Steward in front of a non-production copy of the site and test that legitimate editor, admin and visitor traffic still passes.
We document each protection rule, its owner and the update that will eventually make it unnecessary.

How we hand over

You receive a written runbook covering rule changes, logging locations and how to roll back a rule that blocks legitimate traffic.
We walk your operations and security staff through how a Security Team advisory maps to a Steward rule and a planned update.
Ownership of the upstream update, the Steward subscription and the site's patch deadlines is recorded by name in the handover.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so rule review can follow each advisory window.
We check that protection rules are retired once the matching core or contributed release is installed.
We confirm the scope of each retainer in writing, including which advisories, environments and rule changes it covers.