June 2026 · 14 min read · Security Testing

Information Disclosure Vulnerabilities: Testing Guide for Web Applications

Information disclosure vulnerabilities are among the most consistently found issues in penetration tests — and often among the most underestimated. An application that leaks stack traces, exposes internal infrastructure paths, reveals user enumeration vectors, or stores credentials in client-accessible locations provides attackers with reconnaissance material that dramatically reduces the effort required for a successful attack.

This guide covers the full taxonomy of information disclosure vulnerabilities, how to test for each class, the tools that surface them, and how to prioritize remediation.

What Is Information Disclosure?

Information disclosure (also called information leakage or data exposure) occurs when an application unintentionally reveals data that could help an attacker understand, map, or compromise the system. Unlike a direct exploit, information disclosure is often a stepping stone — it gives an attacker the context to mount more targeted attacks.

OWASP maps information disclosure across multiple Top 10 categories: it appears explicitly in A02: Cryptographic Failures (sensitive data exposure) and implicitly in A05: Security Misconfiguration (verbose error messages, exposed debug endpoints) and A04: Insecure Design (user enumeration, excessive data in API responses).

Taxonomy: Classes of Information Disclosure

1. Verbose Error Messages and Stack Traces

When an application encounters an unhandled exception and returns a full stack trace to the client, the attacker learns the technology stack, framework versions, internal file paths, class names, and sometimes database query fragments. A Java stack trace exposing Hibernate ORM version 5.4.2 tells an attacker exactly which CVEs to check. A Python traceback exposing /home/deploy/app/models/user.py reveals the deployment directory structure.

Testing approach: trigger error conditions by sending malformed inputs — invalid data types, boundary values, unexpected content types, truncated request bodies. Send Content-Type: application/json with a body of null where an object is expected. Send SQL metacharacters. Send oversized inputs. Watch the response carefully.

# Trigger error conditions with unexpected inputs
curl -X POST https://target.com/api/users \
  -H "Content-Type: application/json" \
  -d "null"

# Send invalid type where number expected
curl -X POST https://target.com/api/orders \
  -H "Content-Type: application/json" \
  -d '{"quantity": "not-a-number", "item_id": "abc\''def"}'

# Oversized field to trigger truncation or buffer handling
python3 -c "import json; print(json.dumps({'name': 'A'*10000}))" | \
  curl -X POST https://target.com/api/profile \
    -H "Content-Type: application/json" -d @-

2. Debug Endpoints and Developer Artifacts

Applications deployed without proper environment separation often leave debug endpoints, admin interfaces, and development tools exposed in production. Spring Boot Actuator endpoints are a classic example — /actuator/env, /actuator/mappings, and /actuator/beans can expose application configuration including database credentials. Django's debug mode at / with DEBUG=True exposes all application settings. Laravel's Telescope endpoint at /telescope exposes request logs and database queries.

Testing approach: enumerate known debug paths for the detected technology stack, examine JavaScript bundles for hardcoded endpoint references, spider the application for unexposed routes.

# Spring Boot Actuator endpoints
for endpoint in env beans mappings health metrics trace sessions; do
  curl -s -o /dev/null -w "%{http_code} /actuator/$endpoint\n" \
    https://target.com/actuator/$endpoint
done

# Common debug/admin paths
wordlist=(debug admin _debug phpinfo.php info.php server-status .well-known/security.txt \
          telescope horizon graphiql swagger swagger-ui api-docs __debug__ _profiler)
for path in "${wordlist[@]}"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://target.com/$path")
  [ "$code" != "404" ] && echo "$code https://target.com/$path"
done

3. Sensitive Data in HTTP Responses

APIs frequently return more data than the client needs — a pattern called over-fetching or mass data exposure (OWASP API Security Top 10, API3). A user profile endpoint that returns the user's password hash, internal user ID, admin flag, or account metadata exposes information that should be filtered at the serialization layer.

Testing approach: examine every API response field. Compare what the application displays in the UI against what the raw API response actually returns. Pay special attention to fields like password, passwordHash, secret, token, apiKey, internalId, isAdmin, and role.

# Fetch your own user profile and inspect all returned fields
curl -s -H "Authorization: Bearer YOUR_TOKEN" \
  https://target.com/api/v1/users/me | jq '.'

# Compare against another user's profile (IDOR check)
curl -s -H "Authorization: Bearer YOUR_TOKEN" \
  https://target.com/api/v1/users/12345 | jq '.'

# Check list endpoints for over-exposure in paginated responses
curl -s -H "Authorization: Bearer YOUR_TOKEN" \
  "https://target.com/api/v1/users?page=1&limit=50" | jq '.items[0]'

4. User Enumeration

When an application responds differently to valid versus invalid usernames during login, password reset, or registration flows, an attacker can enumerate which usernames or email addresses have registered accounts. This is valuable for targeted phishing, credential stuffing attacks, and identifying high-value accounts.

Common patterns: different error messages ("Email not found" vs "Invalid password"), different response times, different HTTP status codes, different redirect targets.

# Compare response time for valid vs invalid username
time curl -s -X POST https://target.com/auth/login \
  -d "email=known-user@target.com&password=wrongpassword" > /dev/null

time curl -s -X POST https://target.com/auth/login \
  -d "email=nonexistent-random-12345@target.com&password=wrongpassword" > /dev/null

# Compare password reset responses
curl -s -X POST https://target.com/auth/reset-password \
  -d "email=known@target.com" | grep -i "message\|error\|found"

curl -s -X POST https://target.com/auth/reset-password \
  -d "email=notexist@example.com" | grep -i "message\|error\|found"

5. Directory Listing and File Exposure

Web servers with directory listing enabled allow attackers to browse folders and discover backup files, configuration files, log files, and source code. Even without listing enabled, predictable file paths — .git/, .env, config.yml.bak, database.sql — are commonly found in production environments.

# Check for exposed .git repository
curl -s https://target.com/.git/config | head -5

# Common sensitive files
sensitive_paths=(.env .env.local .env.production config.yml config.json \
                 database.yml wp-config.php settings.py secrets.yml \
                 id_rsa .ssh/id_rsa backup.sql dump.sql .DS_Store)

for path in "${sensitive_paths[@]}"; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "https://target.com/$path")
  [ "$code" = "200" ] && echo "EXPOSED: https://target.com/$path"
done

# Use gitdumper if .git is accessible
git-dumper https://target.com/.git/ ./recovered-repo/

6. Source Code Disclosure

Source code disclosure can occur through several mechanisms: backup files left with editor extensions (.php~, .bak, .orig), accidental exposure of .git directories, server misconfiguration that serves PHP source instead of executing it, and JavaScript source maps that expose original pre-minified code.

# Check for source map exposure
curl -s https://target.com/static/js/main.abcd1234.js | tail -5
# Look for: //# sourceMappingURL=main.abcd1234.js.map

# Fetch source map if present
curl -s https://target.com/static/js/main.abcd1234.js.map | jq '.sources[]'

# Try common backup extensions
for ext in .bak .backup .old .orig .copy .tmp ~ .swp; do
  url="https://target.com/index.php${ext}"
  code=$(curl -s -o /dev/null -w "%{http_code}" "$url")
  [ "$code" = "200" ] && echo "FOUND: $url"
done

7. HTTP Header Leakage

Response headers frequently disclose technology stack details. X-Powered-By: PHP/8.1.2 tells an attacker exactly which PHP version to check for CVEs. Server: Apache/2.4.50 (Ubuntu) narrows the target considerably. X-AspNet-Version, X-Generator, and custom headers like X-Debug-Token all contribute to fingerprinting.

# Examine all response headers
curl -s -I https://target.com/ | grep -Ei "server|x-powered|x-aspnet|x-generator|via|x-debug"

# Check multiple endpoints — different servers may expose different headers
for path in / /api /admin /login; do
  echo "=== $path ==="
  curl -s -I "https://target.com$path" | grep -Ei "server|x-powered|x-generator"
done

8. Credentials and Secrets in Client-Side Code

Hardcoded API keys, tokens, database connection strings, and internal service URLs in JavaScript bundles are a persistent problem. These range from low-severity (public analytics keys) to critical (cloud provider credentials, payment processor keys, internal service tokens).

# Download and search JavaScript bundles
wget -r -l1 -P ./js-dump https://target.com/ -A "*.js" -q

# Search for common secret patterns
grep -rE "(api[_-]?key|apikey|secret|token|password|credential|aws_|AKIA)" ./js-dump/ \
  --include="*.js" -i | grep -v "node_modules"

# Nuclei has templates for this
nuclei -u https://target.com -t exposures/ -t tokens/

Automated Detection with Nuclei

Nuclei's template library includes hundreds of templates specifically targeting information disclosure — exposed panels, debug interfaces, backup files, sensitive file paths, and technology fingerprinting.

# Run information disclosure templates
nuclei -u https://target.com \
  -t exposures/ \
  -t misconfiguration/ \
  -t technologies/ \
  -t files/ \
  -severity low,medium,high,critical \
  -o results.txt

# Target specific categories
nuclei -u https://target.com -t exposures/tokens/
nuclei -u https://target.com -t exposures/apis/
nuclei -u https://target.com -t exposures/files/

Content Discovery

Automated content discovery finds paths and endpoints that are not linked from the application. Many information disclosure vulnerabilities sit on endpoints that are never publicly referenced — they're only found by brute-forcing paths.

# ffuf for fast content discovery
ffuf -u https://target.com/FUZZ \
  -w /usr/share/wordlists/dirb/common.txt \
  -mc 200,301,302,403 \
  -o content-discovery.json -of json

# Focus on backup and config file patterns
ffuf -u https://target.com/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/CommonBackdoors-PHP.fuzz.txt \
  -mc 200

# Use feroxbuster for recursive discovery
feroxbuster -u https://target.com \
  -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt \
  --status-codes 200,301,302,403 \
  --depth 3

Burp Suite Passive Scanning

Burp Suite's passive scanner automatically flags information disclosure issues as you browse through the application. It catches verbose error messages, technology disclosure headers, interesting comments in HTML source, and known sensitive file patterns. Enable passive scanning at the project level and browse all application functionality — Burp will surface findings without sending any additional requests.

For active discovery, use Burp's content discovery tool under Target → Engagement Tools → Discover Content. It uses a built-in wordlist combined with words discovered from the application to find hidden paths.

Severity Mapping and Prioritization

Remediation

Error handling

Implement centralized error handling that logs detailed stack traces server-side and returns generic error messages to clients. Never include framework names, file paths, SQL queries, or library versions in HTTP responses. In production environments: DEBUG = False in Django, display_errors = Off in PHP, structured error responses in Express.

Secret management

Never hardcode secrets in source code. Use environment variables at minimum; use a secrets manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) for production workloads. Rotate any secret that has been exposed, even briefly — treat disclosure as a confirmed compromise. Run git-secrets or truffleHog in CI/CD to catch secrets before they reach the repository.

API response filtering

Implement explicit allowlists for what each API endpoint returns rather than serializing entire model objects. Use Data Transfer Objects (DTOs) or response schemas to control output. Never pass internal model instances directly to serialization without field filtering.

Disable debug tooling in production

Restrict or remove Spring Boot Actuator endpoints, disable Django Debug Toolbar, remove PHPInfo pages, gate Laravel Telescope behind authentication and IP restrictions. Treat debug interfaces as production attack surface — because they are.

Web server configuration

Disable directory listing (Options -Indexes in Apache, autoindex off in nginx). Remove Server and X-Powered-By headers. Use ServerTokens Prod in Apache. Block access to .git, .env, and common backup file patterns at the web server layer, not just the application layer.

Testing Coverage Checklist

• Error condition responses — malformed inputs, boundary values, unexpected content types
• Debug endpoints — Spring Actuator, Django debug, PHPInfo, framework-specific admin routes
• Backup files — .bak, .old, .orig, editor swap files
• Sensitive file paths — .env, .git, config.*, database dumps
• JavaScript bundle analysis — secrets, internal URLs, source maps
• API response over-fetching — compare raw response against rendered UI
• User enumeration — login, password reset, registration, forgot username flows
• HTTP response headers — Server, X-Powered-By, X-Generator, custom debug headers
• Directory listing — common directories and upload paths
• HTML source comments — developer notes, internal URLs, disabled features