Information Disclosure Remediation

Every piece of information your server reveals about itself reduces the work an attacker needs to do. A Server: Apache/2.4.51 header tells them exactly which CVEs to try. A stack trace in a 500 response exposes file paths, framework versions, and database connection strings. HTML comments left by developers reveal internal endpoints and business logic. Source maps hand over your entire client-side codebase in readable form.

None of these disclosures are vulnerabilities by themselves. They are reconnaissance gifts that make real vulnerabilities easier to find and exploit. Information disclosure is one of several finding categories that passive web vulnerability assessment surfaces without sending any exploit payloads.

Server Version Headers

Web servers and application frameworks broadcast their identity and version in response headers by default. The two primary offenders are Server and X-Powered-By.

Nginx

By default, Nginx sends Server: nginx/1.24.0. To suppress the version number:

# In http, server, or location block
server_tokens off;

This changes the header to Server: nginx without the version. To remove the header entirely, you need the ngx_http_headers_more_module:

more_clear_headers 'Server';

Apache

Apache sends Server: Apache/2.4.51 (Ubuntu) OpenSSL/3.0.2. Reduce it to just the product name:

# In httpd.conf or apache2.conf
ServerTokens Prod
ServerSignature Off

ServerTokens Prod reduces the header to Server: Apache. ServerSignature Off removes the server version from error pages.

Express.js

Express sends X-Powered-By: Express by default. Disable it:

app.disable('x-powered-by');

Or use Helmet, which disables it automatically along with setting other security headers:

import helmet from 'helmet';
app.use(helmet());

IIS

IIS sends Server: Microsoft-IIS/10.0 and X-Powered-By: ASP.NET. Remove them in web.config:

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <remove name="X-Powered-By" />
    </customHeaders>
  </httpProtocol>
  <security>
    <requestFiltering removeServerHeader="true" />
  </security>
</system.webServer>

The removeServerHeader attribute requires IIS 10+. On older versions, use URL Rewrite to blank the header.

Disabling Debug Mode in Production

Debug mode is the single most dangerous configuration to leave enabled in production. It typically displays full stack traces, environment variables, SQL queries, and internal file paths on every error.

Django

# settings.py
DEBUG = False
ALLOWED_HOSTS = ['yourdomain.com', 'www.yourdomain.com']

Django's debug page shows the full settings dictionary, all installed middleware, URL patterns, template search paths, and the traceback with local variables. With DEBUG = True in production, a single 404 or 500 gives an attacker a complete map of your application.

Laravel

# .env
APP_DEBUG=false
APP_ENV=production

Also ensure the debug key in config/app.php reads from the environment variable:

'debug' => (bool) env('APP_DEBUG', false),

Laravel's debug page (powered by Ignition) shows the full request, environment variables, database queries, and application configuration.

Spring Boot

# application.properties
server.error.include-stacktrace=never
server.error.include-message=never
server.error.whitelabel.enabled=false

The default Whitelabel error page shows class names and stack traces. Disable it and configure a custom error controller that returns generic messages.

ASP.NET Core

// Program.cs
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/error");
}

Never use app.UseDeveloperExceptionPage() outside the development environment. The developer exception page shows the full stack trace, request headers, cookies, and routing data.

Stripping HTML Comments

Developers leave comments in HTML templates during development: internal URLs, TODO notes, feature flags, API endpoints, and sometimes credentials. These comments ship to production in the HTML source, visible to anyone who views the page source.

Webpack (via html-webpack-plugin):

new HtmlWebpackPlugin({
  minify: {
    removeComments: true,
    collapseWhitespace: true,
  },
});

Vite: Vite minifies HTML in production builds by default, which removes comments. Verify by checking your dist/index.html for leftover comments.

Server-side templates: Add a post-processing step or template filter that strips comments. For example, in Django:

# middleware.py
import re

class StripHtmlCommentsMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        response = self.get_response(request)
        if 'text/html' in response.get('Content-Type', ''):
            response.content = re.sub(
                rb'<!--[\s\S]*?-->',
                b'',
                response.content
            )
        return response

Be careful not to strip conditional comments used by older IE compatibility hacks if you still need them (unlikely in modern applications).

Disabling Source Maps in Production

JavaScript source maps (.js.map files) reverse the minification and bundling process, giving an attacker your original source code with variable names, comments, and file structure intact.

Webpack:

// webpack.config.js
module.exports = {
  mode: 'production',
  devtool: false,
};

Vite:

// vite.config.js
export default defineConfig({
  build: {
    sourcemap: false,
  },
});

Create React App:

# .env.production
GENERATE_SOURCEMAP=false

If you need source maps for error monitoring (Sentry, Datadog, Bugsnag), upload them to the monitoring service during the build step and exclude .map files from your deployment artifact. This gives you readable stack traces in your monitoring dashboard without exposing source code to the public. For web server rules that block access to source maps and other sensitive files at the server level, see our sensitive file exposure prevention guide.

Why Each Leak Matters

From an attacker's perspective, information disclosure builds a target profile:

• Server/framework version narrows the CVE search. Instead of trying thousands of exploits, they try the five that match your exact version.
• Stack traces reveal file paths (/var/www/app/controllers/PaymentController.py), database types, and ORM versions. This maps your internal architecture.
• HTML comments may contain internal hostnames (<!-- TODO: move to api-internal.corp.local -->), disabled features, or authentication bypass notes left during development.
• Source maps expose business logic, API endpoint patterns, authentication flows, and hardcoded configuration that may include tokens or keys.

Each disclosure on its own may seem minor. Combined, they give an attacker a detailed blueprint before they send a single malicious request. Information disclosure is just one piece of the broader security misconfiguration remediation puzzle that spans headers, TLS, DNS, and email authentication.

Verification

Check your response headers with curl:

curl -sI https://yourdomain.com | grep -iE "server|x-powered-by"

Neither header should reveal version numbers or framework names. Trigger an error (request a nonexistent page, submit invalid data) and verify that the response contains a generic error message, not a stack trace. View your page source and search for <!-- to find residual HTML comments. Check whether .map files are accessible by requesting a known JavaScript bundle path with .map appended. Run a CyberShield scan for automated detection of all these disclosure vectors.