Skip to content

CWE-209: Information Exposure Through Error Message

Overview

This guidance helps interpret DAST findings for CWE-209: Information Exposure Through Error Messages. During dynamic scanning, the scanner detected that application error responses disclosed detailed diagnostic information - such as stack traces, database errors, or file paths - that reveal internal implementation details.

What the DAST scanner detected:

  • Stack traces in HTTP responses showing framework internals, function calls, and line numbers
  • Database error messages revealing table/column names, SQL syntax, or connection strings:
    • mysqli_query(): (HY000/1054): Unknown column 'user_id' in 'where clause'
    • ORA-00904: "PASSWRD": invalid identifier
    • psql: FATAL: database "production_db" does not exist
  • File path disclosure in errors (FileNotFoundError: /app/src/controllers/uploads/user123/profile.jpg)
  • Framework-specific debug pages:
    • Django: Detailed error page with full stack trace, local variables, SQL queries
    • Laravel: Whoops error page showing file contents and environment
    • Express: Default error handler exposing stack traces
  • Exception type and message revealing business logic or validation rules

Key DAST evidence:

  • Error response shows full stack trace:

    Traceback (most recent call last):
  File "/app/views.py", line 42, in get_user
    user = User.objects.get(id=request.GET['id'])
DoesNotExist: User matching query does not exist.
  • SQL error: Warning: mysqli_fetch_array() expects parameter 1 to be mysqli_result, boolean given in /var/www/html/login.php on line 23
  • Framework version in error page: Laravel 9.52.16 - Symfony Exception
  • Error reveals internal paths: IOError: [Errno 2] No such file or directory: '/opt/app/uploads/users/sensitive_doc.pdf'

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 exception leakage
  • 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

Use the HTTP request URL to locate the code:

# Search for error-prone endpoints
grep -r "/api" src/
grep -r "try.*except" src/
grep -r "try.*catch" src/
grep -r "error_handler" src/

Locate the Route Handler

Common patterns to search for:

  • Python Flask/Django: Error handlers, exception middleware
  • Node.js Express: app.use() error middleware
  • Java Spring: @ExceptionHandler, error pages
  • ASP.NET: Application_Error, exception filters
  • PHP: set_error_handler(), try/catch blocks

Find Error Handling

Search for error handling code:

# Find error handling
grep -r "except.*as e" src/                  # Python
grep -r "catch.*error" src/                  # JavaScript
grep -r "catch.*Exception" src/              # Java/C#
grep -r "error_reporting" src/               # PHP

Trace to Vulnerable Operation

Look for information disclosure in:

  • Detailed error messages: Stack traces, SQL errors, file paths
  • Debug mode enabled: Verbose error output in production
  • Exception details: Showing internal implementation details
  • Database errors: Revealing table/column names
  • File system errors: Exposing server paths
  • Output rendering or response construction
  • Authentication or authorization checks

Remediation

Core Principle: Never expose internal error details to clients; error responses must be constructed from a fixed, server-controlled contract that is independent of internal exception state.

  • Error responses should be generated from a fixed set of user-safe messages
  • Internal exception details must be logged, not returned
  • Error handling must be centralized and environment-invariant

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

Language-Specific Guidance

The static guidance provides detailed remediation steps for many languages. If you need language-specific examples:

Verification and Follow-Up Testing

After applying the fix:

Reproduce the Vulnerability

# Trigger errors to see verbose messages
curl "http://localhost:3000/user/9999999"  # Non-existent ID
curl -X POST "http://localhost:3000/api/data" -d "invalid json"
curl "http://localhost:3000/file?name=nonexistent.txt"

# Or use browser DevTools Network tab

Verify the Fix

  • Confirm generic error messages shown to users
  • Verify detailed errors logged server-side only
  • Check debug mode disabled in production
  • Ensure stack traces not exposed
  • Test that error messages don't leak paths, versions, or internal details

Test Edge Cases

# Trigger different error types
# SQL errors
/api/user?id=abc  # Invalid type

# File not found
/download?file=nonexistent.pdf

# Invalid JSON
curl -X POST "/api/data" -H "Content-Type: application/json" -d "invalid"

# Division by zero or null pointer
/calculate?num=5&divisor=0

# Look for leaked information:
# - Stack traces with file paths
# - Database connection strings
# - Internal IP addresses
# - Framework versions
# - Table/column names

# 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