WebOTG Security Testing Library ● Public reference
W WebOTG
Search
WebOTG
Standards Countries Topics Resources About
WEBOTG SECURITY TESTING PROCEDURE

WebOTG-SM-021 — Excessive Information Disclosure Through Error Handling

A structured procedure for identifying application errors, exception responses, debug output and diagnostic information that disclose unnecessary technical details to users or untrusted clients.

WebOTG ID SM-021 OWASP A02:2025 Type Error Handling Method Error Response Analysis Version 1.0
01 / OBJECTIVE

Objective

What are we verifying?

Verify that application errors presented to untrusted users do not unnecessarily disclose internal technical information that could assist reconnaissance, exploitation or identification of the application's underlying infrastructure.

Applications inevitably encounter invalid requests, missing resources, unexpected input and internal failures. The security requirement is not that errors never occur, but that externally visible error responses expose only information appropriate for the requesting user.

Detailed diagnostic information should normally remain available to authorized operators through controlled logging and monitoring systems rather than being returned directly to clients.

A useful error message does not require an internal stack trace

Client-facing responses can provide a meaningful error identifier and appropriate user guidance without exposing source-code paths, framework internals, database details or debugging output.

02 / SCOPE

Scope

Review error behavior across:

Invalid URLs and missing resources
Invalid HTTP methods
Invalid parameters and malformed requests
Authentication and authorization failures
Application exceptions
Database or backend failures
Reverse-proxy and gateway errors
Debug and diagnostic endpoints
Development-mode responses accidentally deployed
03 / PREREQUISITES

Prerequisites

Authorization Confirm authorization to test the application and trigger error conditions.
Application architecture Understand relevant application, framework, API, database and proxy layers.
Logging model Where possible, understand how detailed diagnostic information is captured internally.
Environment Determine whether the target represents production, staging or another controlled environment.
04 / METHODOLOGY

Methodology

Trigger controlled error conditions and inspect the resulting client-visible response. Determine whether the information disclosed exceeds what is necessary for the requesting party.

Review Purpose
Response body Identify stack traces, exception details, source fragments and internal messages.
Response headers Identify unnecessary technology, framework or infrastructure information.
Error status Confirm that the application returns appropriate HTTP status behavior.
Error consistency Determine whether different routes or environments expose inconsistent detail.
Diagnostic correlation Determine whether detailed diagnostics are available internally without being exposed to the client.
05 / PROCEDURE

Test procedure

01
Establish the normal error baseline Request a known-invalid resource and record the normal error response.
02
Trigger controlled input errors Submit malformed or invalid values appropriate to the application's documented functionality.
03
Test application failure paths Where safely possible, exercise predictable failure conditions such as invalid identifiers, missing resources or unsupported operations.
04
Inspect response content Review the response body and headers for internal implementation or infrastructure information.
05
Compare application states Compare unauthenticated, authenticated and privileged contexts where applicable.
06
Determine information sensitivity Establish whether the disclosed information materially assists reconnaissance or exploitation.
06 / DISCLOSURE TYPES

Information disclosure types

STACK TRACES

Internal call stacks, class names, methods, source files and line numbers.

SOURCE PATHS

Server filesystem paths, application directories and deployment locations.

DATABASE ERRORS

SQL statements, table names, database engines or internal connection information.

FRAMEWORK DETAILS

Framework exceptions, debug pages and unnecessary implementation details.

INTERNAL HOSTS

Private hostnames, internal service addresses and infrastructure identifiers.

CONFIGURATION

Environment variables, configuration fragments, feature flags or deployment information.

Example unsafe response

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

RuntimeException:
Database connection failed

at /var/www/application/src/Database/UserRepository.php:184
at /var/www/application/src/Controller/UserController.php:72

SQLSTATE[HY000]:
Connection refused to database.internal.example

Example safer response

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

{
    "error": "An unexpected error occurred.",
    "request_id": "REQ-2026-000184"
}
Correlation identifiers are useful when properly designed

A non-sensitive request or correlation identifier can allow support personnel to locate detailed server-side diagnostics without returning the diagnostic content itself to the client.

07 / ASSESSMENT

Assessment

Condition Assessment consideration
Generic client-facing error Normally appropriate if it does not hide information required for legitimate users.
Stack trace exposed Assess disclosed paths, classes, methods and whether they materially assist reconnaissance or exploitation.
Database details exposed Determine whether database technology, schema information or query details are unnecessarily disclosed.
Framework debug page exposed Determine whether development diagnostics are enabled in an untrusted environment.
Technology identification only Do not automatically classify a minor technology disclosure as a vulnerability. Consider actual security impact.
08 / EXPECTED RESULT

Expected result

Pass condition

Client-facing error responses provide appropriate information for legitimate users without exposing unnecessary implementation, infrastructure or diagnostic details.

Detailed diagnostic information should be available to authorized operators through controlled server-side logging and monitoring mechanisms.

09 / FAILURE CRITERIA

Failure criteria

Production error responses expose server-side stack traces or source-code locations.
Database errors reveal sensitive implementation, schema or query information.
Debug or development-mode output is exposed to untrusted clients.
Error responses expose internal infrastructure details that materially assist reconnaissance.
Exception information includes secrets, credentials, tokens or other sensitive configuration data.
Different application routes expose excessive diagnostics inconsistently.
Example finding INFORMATION DISCLOSURE

A production endpoint returns an unhandled exception containing a server filesystem path, source-code location and backend implementation details. The information is unnecessary for the requesting client and provides useful reconnaissance data about the application's internal structure.

10 / REMEDIATION

Remediation

Separate client-facing error handling from internal diagnostic handling. Return controlled error responses while retaining sufficient server-side information for incident investigation and operational troubleshooting.

Recommended approach

  1. Disable development and debug modes in production.
  2. Implement centralized exception handling.
  3. Return generic client-facing error messages where detailed diagnostics are unnecessary.
  4. Record detailed diagnostics in protected server-side logs.
  5. Use correlation or request identifiers where useful for operational troubleshooting.
  6. Prevent credentials, tokens, secrets and sensitive configuration values from entering error responses or logs.
  7. Review reverse-proxy and gateway error pages in addition to application-generated errors.
  8. Apply consistent error handling across all production routes and application states.
  9. Ensure error logging itself is protected against unauthorized access.
  10. Re-test representative failure conditions after remediation.

Conceptual error-handling architecture

Production error flow EXAMPLE 
Application exception
        |
        +----------------------+
        |                      |
        v                      v
Server-side logging      Error handler
        |                      |
        |                      v
        |              Generic response
        |                      |
        |                      v
        |                 Client
        |
        v
Detailed diagnostics
for authorized operators
Do not solve this by deleting all error logging

Removing diagnostic information entirely is not a proper security fix. It can destroy the ability to investigate failures and security incidents. The correct boundary is to keep detailed diagnostics server-side and control who can access them.

11 / VERIFICATION

Verification

01
Repeat the original failure condition Reproduce the same authorized test that exposed the excessive information.
02
Inspect the client response Confirm that stack traces, source paths, backend details and sensitive configuration are no longer exposed.
03
Verify useful client behavior Confirm that the application still returns an appropriate status and understandable error response.
04
Verify server-side diagnostics Confirm that authorized operators can still obtain sufficient diagnostic information through protected logging or monitoring.
05
Test multiple failure paths Verify that the remediation applies consistently to application, proxy, API and error-handler paths where applicable.
06
Confirm sensitive data protection Verify that credentials, tokens, secrets and other sensitive values are not returned in error responses.
PASS

Error responses are appropriately sanitized and detailed diagnostics remain available through controlled internal mechanisms.

FAIL

Material internal or sensitive information remains exposed to the client.

NOT TESTED

Relevant failure conditions could not be adequately exercised or evaluated.

12 / EVIDENCE

Evidence requirements

Endpoint and failure condition tested
Original response demonstrating disclosure
Specific information disclosed
Security relevance and impact
Before-remediation evidence
Error-handling configuration or implementation evidence
Post-remediation response
Server-side diagnostic verification where applicable
Multiple failure-path verification
Final PASS / FAIL determination
Never publish sensitive error evidence

Sanitize credentials, API keys, session tokens, personal information, private hostnames and other sensitive values before publishing screenshots, response captures or examples.

13 / CLASSIFICATION

Classification

WebOTG procedure WebOTG-SM-021
OWASP category A02:2025 — Security Misconfiguration
Procedure type Error handling and information disclosure review
Assessment result PASS / FAIL / NOT TESTED
Finding severity Determine from the sensitivity of the disclosed information, exposure boundary, exploitability and resulting impact.
WebOTG classification notice

WebOTG-SM-021 is a WebOTG-defined verification procedure. The identifier is not an OWASP-defined test identifier.

14 / REFERENCES

References

Source Relevance
OWASP Top 10:2025 — A02 Security Misconfiguration category.
OWASP Web Security Testing Guide Testing methodology relevant to error handling and information disclosure.
OWASP Application Security Verification Standard Verification requirements relevant to secure error handling and information exposure.
Application security architecture Defines appropriate separation between client-facing errors and internal diagnostics.
Organizational logging policy Defines requirements for protected server-side diagnostic information.

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.