WebOTG-SM-013 — Excessive Error Information Disclosure

Objective

Applications inevitably encounter invalid requests, failed operations and unexpected conditions. Error handling becomes a security concern when responses expose information that an untrusted user does not need to know.

Examples include stack traces, source-code locations, internal hostnames, filesystem paths, database details, framework diagnostics, configuration values and debugging information.

Scope

Review error handling across:

Prerequisites

Methodology

Generate controlled error conditions and inspect the resulting client response. Determine whether the response contains information unnecessary for the client to understand or recover from the error.

Test procedure

Error categories

Example of excessive disclosure

{
    "error": "DatabaseException",
    "message": "Query failed",
    "sql": "SELECT * FROM users WHERE id = ?",
    "database": "production_users",
    "host": "db-internal-02",
    "source": "/var/www/app/src/UserRepository.php:184",
    "trace": "..."
}

The client generally does not require the SQL statement, internal database name, internal hostname, source path or stack trace to understand that the request failed.

Preferred client-facing response

{
    "error": "request_failed",
    "message": "The request could not be completed.",
    "request_id": "8f31c2a1"
}

Detailed diagnostic information should remain in controlled server-side logging and be associated with the request identifier where appropriate.

Assessment

Expected result

Production systems should not expose development diagnostics such as stack traces, source locations, debugging panels or backend exception details to untrusted clients.

Failure criteria

Remediation

Separate client-facing error handling from internal diagnostics. The client should receive a controlled error representation, while detailed diagnostic information should be captured through protected operational channels.

Recommended approach

1. Implement centralized exception and error handling.
2. Disable verbose production error output.
3. Return generic client-safe error messages.
4. Use stable error codes where appropriate.
5. Generate a request or correlation identifier for troubleshooting where appropriate.
6. Record detailed diagnostic information in protected server-side logs.
7. Ensure sensitive values are excluded from logs as well as client responses.
8. Configure framework and reverse-proxy error pages appropriately for production.
9. Apply consistent handling across HTML and API responses.
10. Re-test error paths after deployment configuration changes.

Example error-handling model

Application error
       |
       v
Central error handler
       |
       +----------------------+
       |                      |
       v                      v
Server-side log         Client response
       |                      |
Detailed diagnostics     Safe error message
       |                      |
Request ID  <-------------+
       |
       v
Authorized operations team

Verification

Evidence requirements

Classification

References

WebOTG should maintain official source URLs, source versions and review dates through its content-management system so references can be updated independently of the procedure template.