Framework Disclosure

Application frameworks often advertise themselves in response headers (X-Powered-By: Express, X-AspNet-Version: 4.0.30319, X-Generator: Drupal 9) and in HTML meta tags (<meta name="generator" content="WordPress 6.4">). These signals tell an attacker your stack and frequently the exact version, which narrows CVE research to a single result. Server software fingerprinting lives in the Server Header Disclosure check; this one focuses on the application layer.

How the check works

Per primary host, the check inspects four response headers and the HTML body's <meta name="generator"> tags. Per matching value, it deducts points (out of a 20-point per-host budget):

• Empty header / no meta generator: 0 deduction.
• Name only (no version digits): 10 deduction. Reason: framework_header_present.
• Value contains a version (digits.digits): 20 deduction. Reason: framework_version_exposed.

Deductions stack per host but cap at 20. Score = (20 - total) / 20. The four headers checked are X-Powered-By, X-AspNet-Version, X-AspNetMvc-Version, and X-Generator. Per-host scores are weighted (apex highest) and averaged across all primary hosts. Verdict thresholds: pass at 0.9 and above, warn at 0.45 and above, fail below.

How the verdict maps to evidence

• Pass: no framework headers, no meta-generator tag.
• Warn: name-only signal on at least one host (no version disclosed).
• Fail: any version signal on any host, or multiple name-only signals dragging the average below 0.45.

Evidence shows host_rows with each detected signal: which header (or meta:generator), the observed value, the deduction, and whether the value contained a version.

Special states

• Not Applicable: domain redirects to a different site, or primary serves a default/empty placeholder.
• Degraded: probe data unavailable. Fix Web Assessability first.

Fix: remove framework-disclosure headers and meta tags

There is no benefit to sending these headers in production. Modern frameworks have settings to disable them, and reverse proxies can strip them as a backstop.

Express / Node.js

// At app initialisation, before any middleware:
app.disable("x-powered-by");

// Or via Helmet (also strips it):
import helmet from "helmet";
app.use(helmet.hidePoweredBy());

ASP.NET / IIS

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <remove name="X-Powered-By" />
      <remove name="X-AspNet-Version" />
      <remove name="X-AspNetMvc-Version" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

On classic ASP.NET, also disable HttpRuntime version emission in your application: in code, MvcHandler.DisableMvcResponseHeader = true; for X-AspNetMvc-Version, and in machine.config / web.config <httpRuntime enableVersionHeader="false" /> for X-AspNet-Version.

WordPress

// Add to your theme's functions.php or a small mu-plugin:
remove_action('wp_head', 'wp_generator');                // <meta name="generator">
add_filter('the_generator', '__return_empty_string');    // RSS feed generator
remove_action('wp_head', 'rsd_link');                    // RSD link
remove_action('wp_head', 'wlwmanifest_link');            // Windows Live Writer
remove_action('wp_head', 'wp_shortlink_wp_head');

// Strip X-Powered-By at the web server layer (nginx/Apache snippets below).

Drupal

Drupal exposes X-Generator: Drupal N (Sub-version: ...) by default. Remove via the Remove HTTP Headers module, or configure your front proxy to strip it. Also remove the meta generator tag from your theme's html.html.twig template.

Reverse-proxy strip (catches all of the above)

proxy_hide_header X-Powered-By;
proxy_hide_header X-AspNet-Version;
proxy_hide_header X-AspNetMvc-Version;
proxy_hide_header X-Generator;
proxy_hide_header X-Pingback;
proxy_hide_header X-Drupal-Cache;

Header unset X-Powered-By
Header unset X-AspNet-Version
Header unset X-AspNetMvc-Version
Header unset X-Generator
Header unset X-Pingback
Header unset X-Drupal-Cache

Action: Remove
Header name: X-Powered-By

Repeat for X-AspNet-Version, X-AspNetMvc-Version, X-Generator.

Custom Headers section, Override = Yes, Header value = (empty):
  X-Powered-By
  X-AspNet-Version
  X-AspNetMvc-Version
  X-Generator

(Or use a Lambda@Edge / CloudFront Function to delete the headers from the origin response.)

Verify the fix

• curl -sI https://yourdomain.tld | grep -iE 'x-powered-by|x-aspnet|x-generator|x-pingback' should return nothing.
• View page source. Search for <meta name="generator". Should not appear.
• Wappalyzer or BuiltWith browser extensions show fewer fingerprints; aim for the framework section being empty.
• Re-run the RedScore lookup. Pass requires no framework headers and no meta-generator on every primary host.

Common pitfalls

• Plugin reintroduces a header. WordPress plugins, ASP.NET modules, and Drupal modules can all add their own X-Powered-By or X-Generator. Re-test after each plugin install or upgrade.
• Meta generator added by templates. Theme upgrades and CMS exports often re-include the meta generator tag. Add the removal to your theme's functions or template overrides so it survives updates.
• Headers stripped at CDN, present at origin. If origin is reachable directly (see Origin IP Exposure), the headers are still in the responses an attacker sees on direct probes. Strip at both layers.
• X-Powered-By with a marketing-y value. Some platforms set X-Powered-By to a custom string ("X-Powered-By: Coffee", "X-Powered-By: PHP"). The check still flags non-empty values; remove rather than customize.
• Meta-generator regex misses non-standard formatting. The check uses two regex variants for the meta tag, so most quoting styles are covered. If a custom one slips through, you still benefit from removal even when this check does not flag it.
• Removing headers but leaving the underlying technology unchanged. Fingerprints reduce recon, not exploit feasibility. Keep the actual framework patched (see Stack Exposure Profile).