WebOTG-SM-007 — Error Handling and Information Disclosure

Objective

Error handling is part of the application's security boundary. Invalid requests, malformed input, missing resources and unexpected application failures should result in controlled responses appropriate for the deployment environment.

Production systems should not expose development diagnostics merely because an unexpected condition occurs.

Scope

Review error behavior across representative application surfaces, including:

Prerequisites

Methodology

Generate controlled invalid conditions and inspect the resulting response. The objective is to determine whether the client receives only the information necessary to understand the failure.

Test procedure

Information to look for

Example unsafe response

HTTP/1.1 500 Internal Server Error
Content-Type: text/html

RuntimeException:
Database connection failed

File:
 /var/www/application/src/Database/Connection.php

Framework:
 ExampleFramework 4.x

Stack trace:
 #0 /var/www/application/src/...
 #1 /var/www/application/src/...

The example is intentionally generic. The security concern is the unnecessary disclosure of internal implementation and infrastructure information to the client.

Example controlled response

HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{
    "error": "An unexpected error occurred.",
    "request_id": "8f42c1..."
}

Detailed diagnostics should be retained in appropriate protected server-side logs rather than returned directly to an untrusted client.

Assessment

Expected result

Production responses should not expose stack traces, source-code locations, internal infrastructure details, database diagnostics, secrets or debugging interfaces.

Failure criteria

Remediation

Implement centralized exception handling that separates information intended for the client from diagnostic information intended for authorized operators.

Recommended approach

1. Disable development/debug output in production.
2. Implement centralized exception handling.
3. Return generic client-safe error messages.
4. Log detailed diagnostic information on the server.
5. Restrict access to diagnostic logs and monitoring systems.
6. Remove secrets from exception messages and logs.
7. Review framework and web-server error pages.
8. Configure consistent handling for application, proxy and server-generated errors.
9. Use request or correlation identifiers to connect client errors with protected server-side diagnostics.
10. Test error handling after every major deployment configuration change.

Example application response

try {
    processRequest();
} catch (Throwable $e) {

    $requestId = createRequestId();

    logException($requestId, $e);

    return jsonResponse(
        500,
        [
            "error" => "An unexpected error occurred.",
            "request_id" => $requestId
        ]
    );
}

The implementation above is conceptual. The exact exception-handling mechanism depends on the application's language and framework.

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.