Skip to content

CWE-215: Information Exposure Through Debug Info

Overview

This guidance helps interpret DAST findings for CWE-215: Information Exposure Through Debug Information. During dynamic scanning, the scanner detected that diagnostic debugging information - such as variable dumps, profiling data, or internal state - was exposed in HTTP responses, typically due to debug mode being enabled in production.

What the DAST scanner detected:

  • Debug output in responses:
    • PHP: var_dump(), print_r() output visible to clients
    • Python: pprint(), debugging print statements
    • JavaScript: console.log() output in server-rendered HTML
  • Performance profiling data showing query execution times, memory usage, or function call counts
  • Verbose logging included in responses (SQL queries executed, internal variable states, request/response cycles)
  • Framework debug tools active in production:
    • Django Debug Toolbar (shows queries, templates, cache hits)
    • Laravel Debugbar (shows database queries, view data, session)
    • Symfony Web Profiler (shows requests, exceptions, logs)
  • Debug endpoints accessible: /debug/vars, /debug/routes, /__clockwork/, /debug/pprof
  • Source code comments or debugging markers in HTML/JavaScript

Key DAST evidence:

  • Response body contains PHP var_dump() output:

    object(User)#3 (4) {
  ["id"]=> int(123)
  ["password_hash"]=> string(60) "$2y$10$..."
}
  • HTML includes SQL query logs: <!-- Query: SELECT * FROM users WHERE id=123 (0.003s) -->
  • Debug toolbar visible in browser showing detailed request/response cycle, database queries, session data
  • Response headers include X-Debug-Token: a1b2c3, X-Debug-Token-Link: /_profiler/a1b2c3
  • JavaScript console output in view source: console.log('User object:', {id: 123, role: 'admin', ...})

Analyzing the Dynamic Scan Result

What the DAST Scanner Found

When reviewing your security scan results, you'll see:

HTTP Request Details

  • URL and endpoint that triggered the finding
  • HTTP method (GET, POST, etc.)
  • Query parameters or form data with test payloads
  • Request headers and body content

HTTP Response Evidence

  • Response showing the vulnerability manifestation
  • Evidence of improper handling or diagnostic information exposure
  • Runtime behavior indicators

Attack Vector

  • Which parameter or input is vulnerable
  • Type of exploitation possible
  • Context where the vulnerability appears

Mapping DAST Findings to Source Code

Find the Vulnerable Endpoint

Search for error handling and debug code:

# Search for debug/error output
grep -r "DEBUG" src/
grep -r "traceback" src/
grep -r "printStackTrace" src/
grep -r "var_dump" src/

Locate Error Handlers

Common patterns to search for:

  • Python: traceback.print_exc(), DEBUG=True
  • Node.js: console.log(error), stack in responses
  • Java: printStackTrace(), verbose exception handlers
  • C#/.NET: Exception.ToString(), debug mode
  • PHP: var_dump(), print_r(), error_reporting(E_ALL)

Find Debug Output

Search for debug information:

# Find debug output
grep -r "print_exc" src/
grep -r "error.stack" src/
grep -r "Exception.ToString" src/

Trace to Information Leakage

Look for debug info in production:

  • Stack traces: Full stack traces in error responses
  • SQL queries: Raw SQL in error messages
  • File paths: Internal paths exposed (C:\app\src\...)
  • Variable dumps: Debug output showing internal state
  • Profiling data: Performance/timing information
  • Framework errors: Django debug page, Express error page

Remediation

Core Principle: Never expose diagnostic or debugging instrumentation to untrusted clients; runtime responses must be constructed independently of any debug or developer-only state.

→ For comprehensive remediation guidance, see Static CWE-215 Guidance

  • Debug code must not be reachable in production execution paths
  • Responses must not be influenced by debug flags or diagnostic state

Verification and Follow-Up Testing

After applying the fix:

Reproduce the Vulnerability

# Trigger an error
curl "http://localhost/api/user/99999"  # Non-existent ID
curl "http://localhost/api/search?q='"  # SQL error

# Check for stack traces
curl / | grep -i "traceback\|stack\|at line"

Verify the Fix

  • Confirm generic error messages in production
  • Verify stack traces logged but not displayed
  • Check debug mode disabled
  • Ensure file paths not exposed
  • Test SQL errors show generic message

Test Edge Cases

# Trigger various errors
curl /nonexistent  # 404 with stack trace?
curl -X POST /api/user -d "invalid json{"  # Parse error
curl "/api/search?q='OR'1'='1"  # SQL error

# Check error responses
# Should NOT contain: stack traces, file paths, SQL queries
# Should contain: generic "An error occurred" message

# Or use browser DevTools Network tab to copy as cURL

Re-run DAST Scanner

Run your dynamic scanner again on the fixed endpoint to confirm remediation.

Additional Resources