Fixing what Drubix finds

Security headers

Missing headers are the single most common finding, and can be fixed in three different places depending on how the site is actually deployed — pick whichever matches your setup, you only need one.

OPTION A — AT THE CDN/EDGE

If the site sits behind a CDN (Cloudflare, Fastly, etc.), this is usually the best option — it works even when the origin server's own config is hard to change. In Cloudflare: Rules → Transform Rules → Modify Response Header, or their newer Snippets feature for more control. No application code changes needed.

OPTION B — AT THE WEB SERVER

Applies to every request regardless of what the application does — a good single place to set this once.

Nginx:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;" always;

Apache (.htaccess or vhost):

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"

OPTION C — INSIDE DRUPAL

Install the Security Kit (seckit) contrib module. It adds a UI at /admin/config/system/seckit covering all of these, including CSP — useful when you don't control the web server layer directly, which is common when hosting is managed by someone else.

A note on Content-Security-Policy specifically: don't jump straight to enforcing it. Ship it as Content-Security-Policy-Report-Only first, point report-uri/report-to somewhere you can actually see the reports, and watch for a week or two what it would have blocked — inline scripts, third-party widgets, tag managers — before switching to the real enforcing header. Going straight to enforcing is the most common way this breaks a production site.

Exposed paths

A publicly reachable .git directory, .env file, or composer.lock is a deploy-process problem, not a code problem — the fix is making sure these never reach the webroot in the first place.

• .git exposed — the deploy process is copying the whole repository, including .git/, into the web-served directory. Fix the deploy step to exclude it, or better, deploy from a build artifact that never contains it at all.
• .env exposed — same root cause. Also confirm the web server explicitly denies dotfiles:

  location ~ /\.(?!well-known) { deny all; }

• composer.lock exposed — not sensitive on its own, but it hands an attacker your exact dependency versions for free. Block it explicitly alongside the dotfile rule above.

Outdated core or contrib modules

Once the connector module is installed and a finding shows a confirmed version match, the finding itself gives you the exact upgrade command — but the full sequence that actually matters in practice:

1. Read the module's release notes first, not just the security advisory — check for breaking changes
2. Apply the upgrade on staging first, never directly on production
3. Run the command from the finding, e.g. composer require drupal/webform:^6.2.5
4. Run any pending schema updates: drush updatedb -y
5. Clear caches: drush cr
6. Re-scan in Drubix to confirm the finding actually clears

Unmaintained modules

A module flagged as unmaintained isn't necessarily vulnerable today, but it will never receive a security fix if one is needed later — there's no maintainer left to issue one. Options, in order of preference:

• Check drupal.org for an actively maintained fork or replacement module covering the same functionality
• If nothing else covers it, evaluate whether the site actually still needs that functionality at all — sometimes the real fix is removing it, not replacing it
• As a last resort, if the module is small and genuinely needed, forking it into the site's own codebase puts the maintenance burden on you explicitly, rather than an unmaintained project silently carrying the risk

Permissions & hardening

These findings only appear with the connector installed — they come from the site's actual role/permission configuration, not anything visible externally.

• Overly broad permissions (e.g. the Anonymous or Authenticated role holding an admin-level permission) — review at /admin/people/permissions. A permission like "Administer permissions" or "Execute PHP code" should never sit on a public-facing role.
• Hardening issues (e.g. PHP filter module enabled, error reporting set to display errors in production) — each finding names the specific setting; most trace back to /admin/config/development/logging or the relevant module's own settings page.