How the Drupal Security Review module catches configuration mistakes
The Security Review module scans a Drupal site for common configuration mistakes and lists the ones it finds, so a team can fix them before a release reaches production. Add it when a site is being prepared for launch, after a major configuration change, or as a standing step in the release checklist, because the mistakes it targets tend to appear during builds and deployments rather than in the code itself. It checks settings such as file and directory permissions on the web root, the text formats that allow potentially unsafe markup, and whether error reporting is showing details to anonymous visitors. It is a configuration review, not a penetration test: it does not try to attack the site, and a clean result says nothing about custom code, access bypasses or outdated contributed modules.
Security Review is a contributed module hosted on Drupal.org, so it falls under the same contributed module review that any new code needs. Before adoption, read its *Drupal.org project page* for the supported Drupal core versions, maintenance status, release history and open security coverage, and confirm that the release you install supports the Drupal version your site runs. Confirm also that the checks it runs match the controls your organization has agreed to, since a result that flags a setting your standards require differently should be recorded as an accepted exception rather than silently ignored. Treat the module as a detective control that you run in staging and on each release candidate, and keep its output with the change record so reviewers can see what was checked and what was waived.
Which configuration checks matter most
The Security Review module groups its checks by area, and each one points at a setting that is easy to leave wrong after a build or a migration. The cards below explain what each area protects, what a finding usually means, and where to confirm the current check list before you rely on it in a release gate.
File system permissions
Security Review looks at whether the public files directory, the private files directory and the settings file are writable by the web server user. Writable code or settings files let an attacker who finds an upload or code execution flaw change the site itself. A finding usually means the deployment copied files with broad permissions or the web server runs as the owner of the codebase. Check the private files path outside the web root and confirm that settings.php is read-only in production.
Unsafe text formats
Text formats control which HTML tags, attributes and scripts editors can publish. A format such as Full HTML, when assigned to roles that do not need it, lets authors inject markup that runs in other visitors' browsers. A finding usually means a format was left at its permissive default or granted to anonymous or authenticated roles. Review each format's roles and filters, and confirm that only trusted editors can use the broadest format.
Error display and logging
Verbose error output can expose file paths, database errors and stack traces to anonymous visitors. Security Review flags sites where error display is enabled outside development, which is a common leftover from a build environment. A finding usually means the production settings were never separated from the development profile. Confirm that errors are logged to a restricted channel and not shown on pages, and that the logging module output is routed to a system you monitor.
Cron and update status
Cron runs scheduled tasks such as update checks, queue processing and cache cleanup. If cron stops, security update status goes stale and queued work piles up without notice. A finding usually means cron is disabled, not triggered by the system scheduler, or has not run recently. Pair the check with your advisory process, because the module tells you whether cron is working, not whether a patch is needed.
Database and session settings
Database credentials and session behavior determine how easily an attacker can reach stored data or reuse a logged-in session. Findings in this area often involve database users with more privileges than the application needs, or cookie and session settings that are weaker than the site's risk profile. Confirm with your platform team that the application database user cannot create or drop schemas, and that secure cookie settings match how the site is served over HTTPS.
Which check settings fit which environment
This table compares how Security Review check settings differ across staging, CI pipelines and production, and how to treat findings as blocking, advisory or accepted. Read each row as a decision point, then match it to your change control model. The main takeaway is that interactive runs suit investigation, pipeline runs suit repeatable gates, and every suppression needs a recorded owner and reason.
| Setting or practice | Staging or interactive run | CI or release pipeline | Regulated change control fit |
|---|---|---|---|
| Where checks run | Run from the admin interface on a copy of the site so reviewers can read each finding in context | Run with Drush on every build so the same checks execute against each candidate release | Pipeline runs give a repeatable record. Interactive runs support investigation but need a written result attached to the change |
| Finding severity | Treat findings as information while the team learns which warnings matter for the site | Mark agreed high-risk findings as blocking so a failed check stops promotion | Blocking gates suit controlled environments. Document which findings stop a release and who can change that list |
| Advisory findings | Triage and assign each item to an owner with a target fix | Report advisory findings in the job log without failing the build | Advisory items still need a tracked ticket so they do not become permanent background noise |
| Accepted risk | Record the reason in the review notes while the site is being assessed | Apply a suppression only through a version-controlled exception file with a named approver | Assessors look for a reason, an owner, a review date and a link to the change record for each exception |
| Configuration baseline | Compare settings against the documented baseline after each manual change | Fail the build when file permissions, text formats or error reporting drift from the baseline | Baseline drift is easier to show to auditors when it is caught in the pipeline history |
| Production verification | Run only read-only checks against production, and only with approval from the change owner | Run a scheduled check on production after deployment and send results to the operations queue | Confirm the tool's effect on production with your change board before enabling any scheduled run |
| Environment-specific settings | Expect some findings to differ between local, staging and production because of hosting layout | Keep environment overrides in version control so each pipeline stage evaluates the expected values | Ask your assessor to review the override list, since undocumented differences are a common audit question |
Setting up the module on a staging site first
This sequence installs the Security Review module on a non-production copy of the site, runs its checks under a privileged account, and turns each finding into a recorded decision. The output is a reviewed baseline that shows which settings match the intended design and which need correction before anything reaches production.
Confirm the staging copy matches production
The platform or Drupal lead makes a copy of the production codebase and database on a staging environment with the same PHP version, web server, database engine and file layout. Settings that differ between the copies, such as the hosting user, the public and private file paths and the error display settings, should be listed in advance so the findings can be read correctly. The step is done when the team has a written list of known differences between staging and production.
Install the module with Composer
A developer adds the Security Review module from its Drupal.org project page to the Composer-managed codebase on staging, using the same Composer workflow the team uses for other contributed code, and records the exact version in the lock file. The module is then enabled with Drush or the admin interface. The step closes when the module appears in the module list, the lock file change is committed to the project repository, and the staging site loads without errors.
Run the checks as a privileged admin
A administrator account with full permissions runs the Security Review checks from the module's report page. Running the checks as an anonymous or limited user would produce misleading results, so the account used should be the one that normally manages the site. The step is complete when the check run finishes and the team has a saved list of passed checks and warnings, with the date and Drupal version recorded alongside the report.
Verify file system permissions against the hosting model
A platform engineer compares each file permission finding with the hosting model, which defines who owns the code, who runs the web server process and which directories must be writable. Writable settings and files should be limited to the public and private file directories and any approved temporary location. The check passes when the permissions shown in the report match the documented model on staging, and any remaining writable paths are listed with a reason.
Confirm error display is off for anonymous users
A security engineer requests a deliberately invalid page and a non-existent path as an anonymous visitor from a separate browser session, then checks whether the response shows PHP or Drupal error details. The same check is repeated with the production-like settings in place. The step is done when anonymous responses show a generic error page and the detailed messages appear only in the logs, with the test results saved to the review record.
Review text formats and other findings against design
The site owner and the developer go through each remaining finding, such as text formats that allow embedded HTML, input filters, and settings tied to update or cron status. Each finding is compared with the intended content and editorial design, so an intended exception is not treated as a fault and an unintended exposure is not waved through. The step closes when every finding has a reviewer's note stating whether it is fixed, accepted or deferred.
Record decisions and rerun the checks
The team writes each decision into the project's security decision log with the finding, the chosen action, the owner and the reason, and then applies the agreed fixes on staging. The module is run again to confirm that fixed items have cleared and accepted items match the log. The sequence is complete when the rerun report contains no unexplained warnings and the log is stored with the release documents, ready for the release checks.
Adding Security Review to release checks
The release gate should compare each build against a recorded baseline, not against an absolute clean report. Run the Security Review checks on a staging build that has the production configuration (file system layout, web server, PHP settings and the same enabled modules) and export the results in a form your pipeline can read. Fail the release only on findings that are new since the last accepted baseline and that meet your severity threshold, such as new writable directories, a text format that now allows unsafe markup, or error display left on. Store the baseline as a reviewed file in version control, with each accepted item carrying an owner, a reason and an expiry date, so an accepted exception cannot quietly become permanent. Confirm with the module's documentation on Drupal.org how its results can be exported or read by a script in your version, because the output format determines how much of this gate you can automate.
Keep a manual confirmation step for anything the automated gate cannot judge. The module reports conditions, not intent: a directory it flags as writable may be a deliberate upload location that needs a different control, and a finding that looks harmless on staging may be real on production if the file permissions, PHP user or web server differ. Results also depend on the environment where the check runs, so the reader should decide whether the staging build is representative and record the differences that could change a result. Have a named reviewer sign off on baseline changes and on any exception, and schedule a periodic full review outside the release cycle.
Plan the work before the first pipeline run. Decide who owns the baseline, which findings block a release, how long an accepted item may stand, and what happens when a security advisory affects a module that is already approved. Ask your implementation partner or internal team to document the exact commands, the environment variables and the exit codes the job will use, and to test the gate with a deliberately misconfigured build so you can see that it fails as intended. The cost of this setup is mostly configuration and review time, which recurs each time you change the baseline policy or upgrade Drupal.
Security and operational considerations
The Security Review module is useful only if it is kept current, locked down and fed into a real patch process. The cards below cover the module's own risk, who can see its output, and how findings and repeat checks keep configuration from drifting after launch.
Treat the module as patchable code
Security Review is a contributed module, so it has its own advisory history and update cadence. Watch its project page and the Drupal Security Team advisories, and apply its updates through the same window you use for other contributed code. A checker that is out of date can miss the checks you rely on, and an unpatched contributed module is itself an entry point. Confirm the installed version in every environment, including staging and development copies.
Restrict who can run checks
Running the review and viewing its results should be limited to a small group of administrators, granted through the Drupal permission model rather than shared admin logins. Confirm that anonymous and authenticated roles cannot reach the report page, and that the module is not left enabled on production longer than needed. Audit role assignments as part of the same routine, since the module's output is most useful to someone who already has broad access.
Handle reports as sensitive output
A report that lists file permissions, enabled text formats, error reporting settings and similar details maps out how the site is built. Treat exported or copied results like configuration backups: store them in restricted locations, avoid pasting them into tickets that many people can read, and remove them after the finding is closed. Ask your security team to classify these reports the same way they classify server configuration files.
Feed findings into patch and hardening
Each finding should become a tracked item with an owner, a severity and a deadline, not a note in the report. Some items will be fixed in configuration, others in the web server or PHP settings, and some will need a code change in a custom module. Record which findings were accepted as risk, who approved that decision and when it will be reviewed. This keeps the review useful for audit evidence as well as for engineering work.
Run checks after every deploy
Configuration drifts when someone changes a permission, enables a debugging option or adds a text format during an urgent fix. Add the review to your release checklist so it runs after each deployment and after any change to roles, file system settings or text formats. Compare results with the previous run and investigate new findings before the change is accepted. Record the run date and the site version with each result.
Limits to confirm in your environment
The Security Review module is a useful first pass over Drupal configuration, but its findings only describe what it can see, from where it ran. The cards below set the boundaries your team should document before treating a clean report as evidence of a secure site.
Configuration only, not application logic
The module inspects settings such as file system permissions, text format handling and error reporting. It does not read the logic of custom modules, custom controllers or theme code, so an access check missing from a custom route will not appear in its output. Ask your developers to review custom code separately, and record which custom modules were in scope for any review you run.
Not a penetration test
A configuration check cannot prove that an attacker cannot reach admin paths, abuse file uploads or bypass access in Views and APIs. Treat it as a baseline check, not a test of exploitability. Penetration testing scope is a separate decision, and the findings from this module should feed that scope rather than replace it.
Not the advisory process
Security advisories for Drupal core and contributed projects arrive through the Drupal Security Team and the Wednesday security release window. The module does not tell you whether a installed module has an open advisory, so your patch process must still track advisories and deadlines independently of this tool.
Results depend on where and as whom it runs
File permission and settings checks give different answers depending on the user account, the PHP process owner and the environment. A run from a developer workstation, a container or a production host can produce different findings. Record the environment, user and Drupal version used for each run so results can be compared over time.
Hosting-level headers may be out of view
Security headers, TLS settings and rules set at the web server, load balancer or CDN may sit outside what Drupal can see. Confirm which headers are set where, and check those layers with a separate test. Do not assume a clean module run means the response headers your users receive are correct.
Confirm version compatibility first
Before adding the module to release checks, confirm it supports your Drupal core version and the PHP version on your servers. Check the Drupal.org PHP requirements and the project page for the release you plan to install. Drupal 11 requires PHP 8.3 or later, so confirm this in your own environment before the check runs in a pipeline.
Questions teams ask before adding Security Review
Does the Security Review module cost anything to use?
The module itself carries no license fee. It is contributed code hosted on Drupal.org and is licensed under GPL-2.0-or-later, the same license as Drupal core, and Drupal itself has no paid edition. Confirm the license on the module's project page and in its code before you adopt it, because contributed projects can differ in details. Your real spend is labor: initial setup, triage of findings, fixes, and repeating the check during each release. Setup is usually one-time, while triage and release checks recur. When you request a quote, ask for setup and recurring triage to be priced separately.
How much effort do setup and triage take?
Effort depends mostly on how many findings the first run produces, how many of those findings are expected for your hosting setup, and who has the authority to fix each one. Setup is simpler on a standard server layout. It takes longer when file permissions are controlled by a deployment tool, when the site runs in containers with read-only file systems, or when several multisite instances share one codebase. Triage needs someone who understands the web server, PHP settings and Drupal configuration. Ask the provider to estimate hours by activity: setup, first triage, fixes and each release check.
Can an internal team run Security Review on its own?
In most organizations, a Drupal developer or platform engineer can install and run the module if they have administrative access to the site and to the server settings it reports on. The harder part is judgment: deciding which findings matter in your hosting model and getting the fixes into your deployment pipeline. Teams with no one who reads web server configuration usually need help for the first review, then can run later checks internally. Assign one owner for each finding type, such as file permissions, text formats and error reporting, so no finding is left without a decision.
How long does a first review take?
No duration comes from the module itself, so the length of a first review depends on the site and the team. The main factors are the size of the site, the number of custom modules, whether a staging copy is available, how quickly approvals for permission or configuration changes arrive, and how many findings need a decision. A review that runs against a production-like staging copy with clear owners moves faster than one that waits on access requests. Ask for a written, fixed-scope plan with agreed dates before work starts.
What does the work need from our team?
The review needs a few specific inputs from your team before it starts:
- Administrative access to a staging copy of the site, plus read access to its hosting and deployment configuration.
- Named owners for web server, Drupal configuration and text format decisions.
- A change window and sign-off for fixes, especially for anything that touches production.
- Access to error logs and the settings that control error display, so reported findings can be checked against real behavior.
Agree on who approves risk acceptance for any finding you choose not to fix, and record that decision with the review output.
Does Security Review replace a penetration test?
No. Security Review checks configuration against known misconfigurations, such as unsafe file permissions, text formats and error reporting. It does not test whether custom code can be exploited, whether views or APIs can bypass access rules, or how file uploads behave under attack. A penetration test covers those areas, and its scope should include custom modules and exposed admin paths. Security Review also does not replace patching. Keep core and contributed code current by following advisories from the Drupal Security Team, and run both checks on a schedule that matches your risk.
Where a configuration review fits in a wider Drupal security program
A configuration check with the Security Review module is one control in a Drupal security program, not the program itself. It looks at settings that drift after installation, such as file permissions, text format access and error display, but it does not learn about new vulnerabilities in core or contributed code, and it does not test how the site behaves under attack. Before adding it to release checks, decide which neighboring controls your organization owns internally and which it hands to a partner or a managed service. The main ones are advisory response (the Drupal Security Team publishes advisories with CVE identifiers and risk scores, and security releases arrive on the third Wednesday of the month), security headers, login and password protection, and the scope of any penetration test. Each has its own owner, its own evidence and its own failure mode.
Assign a named owner to each control on paper. A typical split for a regulated site is that the platform team owns patch deployment and the release gate that runs the configuration check, the security team owns the advisory watch and the scope of external testing, and the application team owns headers, login settings and the handling of contributed modules. Ask your partner or internal team to show, in writing, which of these they cover and which they leave to you. Confirm the exact checks the installed Security Review version performs against your Drupal release, since its coverage changes across releases, and record any finding it does not catch as a gap in your own review. The module's output is evidence that a specific set of settings was checked on a given date, not a statement that the site is secure.
How DeployOpen scopes and supports Drupal security checks
DeployOpen treats a Security Review configuration check as one step in a Drupal security program, not a one-time sign-off. We scope the review against your site's actual settings, fix what it finds in your own environment, and hand over a repeatable check that your team can run before every release.
How we scope
- Engagements are fixed-scope, with the Security Review checks, environments and deliverables agreed in writing before work starts.
- The written scope names which environments are reviewed, such as production, staging and the build pipeline.
- Confirm with us which findings are to be fixed by DeployOpen and which are to be reported back for your team to decide.
How we build
- We run the Security Review module against a copy of the live configuration and record each finding with its file permission, text format or error reporting setting.
- We apply fixes through configuration exports and deployment code so changes are version-controlled and reproducible.
- We wire the check into your release pipeline so a failing configuration review blocks promotion to production.
How we hand over
- You receive a written findings register, the remediation changes, and a short runbook for running the check again.
- Documentation records which findings were accepted as risk, with the owner and the reason for each decision.
- Your team walks through the pipeline gate and the review steps with us before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers for sites that change often.
- Under a retainer, we re-run the configuration checks after core and contributed module updates and report new findings.
- Ask any provider to confirm how security advisories from the Drupal Security Team will reach your patch process.
