Skip to content

CWE-209: Error Message Information Leak

Overview

Error Message Information Leak occurs when detailed error messages are exposed to users, revealing sensitive information about the application's internal structure, configuration, or data.

OWASP Classification

A10:2025 - Mishandling of Exceptional Conditions

Risk

Medium: Attackers can use leaked information to map the application, discover vulnerabilities, or craft targeted attacks. This can lead to further exploitation or data breaches.

Remediation Steps

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.

Locate the error message information leak

  • Review the flaw details to identify where detailed error messages are exposed to users
  • Determine what information is being leaked: stack traces, file paths, database errors, internal configuration, SQL queries, user enumeration
  • Trace the error flow: where exceptions are caught and how error messages are returned to users
  • Check error pages: 404, 500, exception handlers, API error responses

Show generic error messages to users (Primary Defense)

  • Display only generic messages in production: "An error occurred", "Invalid credentials", "Resource not found"
  • Avoid exposing technical details: No stack traces, file paths, SQL errors, or internal system information to users
  • Use error codes instead of descriptions: Return error_id or tracking number for support reference
  • Same message for related errors: Use identical message for "user doesn't exist" and "wrong password" to prevent user enumeration
  • Generate unique error IDs: Assign tracking ID to each error for correlation between user message and server logs

Log detailed errors securely on the server side

  • Log full error details server-side: Stack trace, exception message, request details, user context, timestamp
  • Include error tracking ID: Log the same error_id returned to user for troubleshooting correlation
  • Restrict log access: Ensure only authorized personnel (ops, dev) can access detailed error logs
  • Never log sensitive data: Don't log passwords, tokens, credit cards, PII in error logs
  • Use structured logging: Separate log fields (timestamp, level, message, context) for better analysis

Validate and sanitize all error output

  • Don't include user input in errors: If unavoidable, sanitize and truncate user data before including in error messages
  • Remove or mask sensitive data: Redact credentials, tokens, PII from any error output
  • Disable debug mode in production: Turn off verbose error pages, stack trace display, debug flags
  • Configure custom error pages: Implement generic 404, 500 error pages that don't reveal framework or version information

Monitor and audit error reporting

  • Regularly review error logs for sensitive information leaks (search for passwords, tokens, internal paths in logs)
  • Alert on repeated or suspicious error patterns (may indicate attack attempts or application issues)
  • Monitor error rates and types for anomalies (spike in 500 errors, unusual error patterns)
  • Review framework error handling configuration (disable debug modes, stack trace exposure)

Test the error handling fix thoroughly

  • Test with invalid inputs to trigger various errors (malformed data, missing parameters, wrong types)
  • Verify only generic messages shown to users (no stack traces, paths, or technical details)
  • Verify detailed errors logged server-side with tracking IDs
  • Test error pages (404, 500) display generic messages
  • Check API error responses are properly formatted without exposing internals
  • Re-scan with security scanner to confirm the issue is resolved

Dynamic Scan Guidance

For guidance on remediating this CWE when detected by dynamic (DAST) scanners:

Common Vulnerable Patterns

Exposing Stack Traces and Exception Details to Users

# Dangerous: shows internal error details to user
try {
    perform_operation();
} catch (Exception e) {
    // WRONG: Exposes stack trace, database errors, file paths
    return_to_user(e.message);
    return_to_user(e.stack_trace);
}

Why this is vulnerable: Exposing raw exception messages and stack traces reveals sensitive internal information including file paths, database schema, SQL queries, library versions, and code structure, allowing attackers to map the application architecture, identify vulnerable dependencies, and craft targeted attacks based on exposed implementation details.

Secure Patterns

Generic Error Messages with Server-Side Logging

# Safe: generic message to user, detailed logging server-side
try {
    perform_operation();
} catch (Exception e) {
    // Log full details server-side
    error_id = generate_unique_id();
    log_error(error_id, e.message, e.stack_trace, request_details);

    // Return only generic error with tracking ID
    return_to_user({
        error: "An error occurred",
        error_id: error_id,
        message: "Please contact support with this error ID"
    });
}

Why this works: Separating user-facing error messages from internal error logging implements defense-in-depth by revealing no technical details to potential attackers while maintaining full diagnostic capability for developers and operations teams. The generic error message ("An error occurred") provides no actionable intelligence about system internals, database schema, file paths, or library versions that attackers could exploit. The unique error_id creates a correlation between what the user sees and what's logged server-side, allowing support teams to troubleshoot issues without exposing sensitive details. Server-side logging captures the complete exception context (stack trace, request parameters, user session) in a secure location with access controls, ensuring debugging information exists but isn't accessible to untrusted parties. This pattern prevents information leakage attacks where attackers deliberately trigger errors to map application structure, discover SQL injection points, or identify vulnerable dependencies.

Language-Specific Guidance

  • Java - Spring @ExceptionHandler, ResponseEntity, custom error pages
  • JavaScript/Node.js - Express error middleware, error ID generation, production config
  • Python - Flask errorhandler decorator, generic exceptions, logging with UUID

Additional Resources