Information Disclosure Vulnerabilities: What They Reveal and How to Stop Them

Run a free ZeriFlow scan to find out exactly what information your site is leaking right now.

Why Information Disclosure Matters

Consider the attack chain: An attacker identifies that your server returns X-Powered-By: PHP/7.4.3. PHP 7.4.3 has several known CVEs. The attacker now has a targeted exploit path that might have taken hours of guessing to discover otherwise.

Or: your application returns detailed stack traces on errors, revealing your database schema, file paths, and dependency versions. The attacker uses this to craft a precise SQL injection payload.

Information disclosure turns a generic attack into a surgical one. Closing these leaks doesn't stop determined attackers, but it meaningfully raises the cost of exploitation.

Vector 1: HTTP Response Headers

X-Powered-By

The most widely exposed technology fingerprint:

This header is sent by default by PHP, Express.js, and ASP.NET. It directly identifies the framework and version, which an attacker can cross-reference against CVE databases.

Fix: Remove the header at the web server or application level.

• PHP: expose_php = Off in php.ini
• Express.js: app.disable('x-powered-by') or use the helmet middleware
• ASP.NET: Remove from web.config custom headers

Server Header

Reveals the web server software and version. Some configurations also include the OS.

Fix: Configure the server to suppress or minimize the header.

• Apache: ServerTokens Prod (returns just Apache)
• Nginx: server_tokens off
• IIS: Remove via URL Rewrite module or ARR

X-AspNet-Version / X-AspNetMvc-Version

Exposes precise .NET and MVC versions. Remove via web.config:

ZeriFlow checks all these headers and flags any that expose version information.

Vector 2: Verbose Error Messages

Development-mode error pages that leak to production are one of the most common and impactful information disclosure sources.

What Gets Exposed

• Stack traces: Full call stack with file paths, line numbers, and class names
• Database errors: SQL query structure, table names, column names
• Framework internals: Configuration values, environment variables
• Source code snippets: Actual code lines surrounding the error location
• Dependency versions: Library names and versions in stack frames

Example: Django Debug Page in Production

Django's debug mode returns an HTML page with the full stack trace, local variables at each frame, server settings, and the full SQL query that caused the error — including the query parameters. If DEBUG = True in production, every 500 error becomes a reconnaissance goldmine.

Fix: Ensure DEBUG = False in production for all frameworks. Implement custom error pages that return generic messages. Log detailed errors server-side only.

Vector 3: Directory Listing

When a web server has directory listing enabled and no index.html (or equivalent) exists in a directory, the server renders a browseable list of files:

This exposes every file name, which may include: - Database backups (.sql, .dump) - Configuration files (.env, .config, .bak) - Source code archives (.zip, .tar.gz) - User-uploaded content with private names

Fix: - Apache: Options -Indexes in .htaccess or httpd.conf - Nginx: Remove autoindex on (it's off by default) - Ensure every directory has an index file

ZeriFlow checks for directory listing on common paths as part of its automated scan.

Vector 4: Backup Files and Sensitive File Exposure

Developers and deployment scripts often leave behind files that were never meant to be publicly accessible:

Common Exposed Files

The .git/ Directory Leak

If a .git/ directory is accidentally deployed to the web root, an attacker can reconstruct the entire source code history using tools like gitdumper or git-dumper. This exposes every file ever committed, including credentials that were added and 'removed' from tracked files.

Fix: Exclude .git/ in your web server configuration or deployment pipeline. Never deploy .git/ to production.

ZeriFlow probes for dozens of sensitive file paths including .env, .git/, phpinfo.php, and common backup extensions.

Vector 5: HTML Source Code and JavaScript Comments

Application internals exposed in client-side code:

• HTML comments: <!-- TODO: remove admin bypass before launch -->
• JavaScript source maps: .js.map files expose minified JavaScript back to the original source, including comments and variable names
• Hardcoded API endpoints: Internal API paths, staging URLs, admin endpoints
• Hardcoded credentials: API keys, tokens embedded in JavaScript (extremely common)

Sensitive Data in JavaScript Bundles

React, Angular, and Vue applications bundle environment variables into the compiled JavaScript. REACT_APP_* variables are visible to anyone who views the source. Never put secrets in client-side environment variables.

ZeriFlow's Information Disclosure Checks

ZeriFlow's automated scanner checks for:

• X-Powered-By and Server headers exposing version information
• X-AspNet-Version, X-AspNetMvc-Version
• Directory listing on common paths
• Presence of .env, .git/, phpinfo.php, .htpasswd, web.config.bak and 20+ other sensitive files
• crossdomain.xml and clientaccesspolicy.xml
• Missing X-Content-Type-Options (prevents MIME sniffing)
• Debug headers and internal IP disclosure

Scan your site with ZeriFlow now — see exactly what information your application is broadcasting.

FAQ

Q: Is information disclosure a critical vulnerability or just a low-severity finding?

A: In isolation, information disclosure is typically low-to-medium severity. But in the context of a real attack, it's a force multiplier — it turns generic exploitation attempts into targeted, efficient attacks. Disclosed technology stack + known CVE = critical combined risk. Always fix information disclosure findings.

Q: Does removing the Server header break anything?

A: No. The Server header is purely informational and has no functional role in the HTTP protocol. Removing or minimizing it has zero impact on application functionality.

Q: Can .env files actually be accessed if I don't link to them?

A: Yes. Attackers don't need links — they probe for well-known filenames directly. curl https://yourdomain.com/.env is the first thing many automated scanners do. If the file exists in the web root and directory listings or direct access aren't restricted, it's readable.

Q: What is a source map and why is it a security concern?

A: Source maps (.js.map files) map minified/bundled JavaScript back to the original source code. They're invaluable for debugging but expose your entire source code, comments, variable names, and internal API structure to anyone who downloads them. They should never be deployed to production.

Q: How do I find all the sensitive files my site is exposing?

A: Start with an automated scan like ZeriFlow to catch the most common exposures. Then manually review your deployment process for files that shouldn't be in the web root. Use tools like gobuster or ffuf with a wordlist of common sensitive file names for deeper enumeration.

Conclusion

Information disclosure vulnerabilities are the reconnaissance layer of most real attacks. They're often easy to fix — a configuration change, a removed header, a deployment pipeline update — but left unaddressed they provide attackers with the precise targeting data they need to escalate to more severe exploits.

Automated scanning is the fastest way to get a complete picture of what your application is revealing.

Use ZeriFlow's free security scanner to find and fix your information disclosure vulnerabilities before attackers find them for you.

Further Reading

• RFC 6797 — HTTP Strict Transport Security (HSTS)

<!-- zf-internal-links -->