WebOTG-SM-024 — Verbose Error Messages and Debug Information

01 / OBJECTIVE

Objective

What are we verifying?

Verify that production error responses do not unnecessarily disclose internal implementation, infrastructure or configuration information to untrusted clients.

Applications inevitably encounter invalid requests, unexpected input, unavailable dependencies and internal failures. The security concern is not that an error occurs, but what information the application returns when it occurs.

Development-oriented error responses may reveal framework versions, source-code locations, SQL queries, internal hostnames, filesystem paths, environment variables, service names, request identifiers or other information useful for further attacks.

A generic error is not the same as hiding the error

The application should still log sufficient diagnostic information for authorized operators. The objective is to prevent sensitive implementation details from being returned to untrusted clients, not to eliminate useful server-side logging.

02 / SCOPE

Scope

Review error handling across:

Public web pages

Authenticated application functions

REST and other API endpoints

File upload and processing functionality

Authentication and authorization failures

Input validation failures

Database and external-service failures

Reverse proxy and web-server error pages

Development and diagnostic environments exposed unintentionally

03 / PREREQUISITES

Prerequisites

Authorization	Confirm authorization to generate controlled error conditions against the target application.
Test environment	Prefer a designated test or staging environment where deliberately invalid requests can be generated safely.
Application knowledge	Understand major application functions and expected error-handling behavior.
Logging access	Where available, obtain authorized server-side log access to compare client responses with internal diagnostics.

04 / METHODOLOGY

Methodology

Trigger controlled application errors and examine the resulting client-visible responses. The assessment should distinguish useful business-level error messages from unnecessary disclosure of internal implementation details.

Review	Purpose
HTTP status handling	Determine whether failures return appropriate status codes and controlled responses.
Response body	Identify stack traces, source paths, SQL statements and implementation details.
Response headers	Identify unnecessary technology, framework or debugging information.
API errors	Determine whether structured error responses disclose internal details.
Error consistency	Determine whether different application layers expose inconsistent or verbose failure information.

05 / PROCEDURE

Test procedure

01

Establish a normal baseline Record the normal response format, status codes and expected application behavior before deliberately triggering errors.

02

Trigger invalid input Submit controlled malformed, incomplete or invalid input through authorized application functionality.

03

Test invalid resource references Request non-existent resources or otherwise controlled invalid application states.

04

Review application failures Where safely reproducible, exercise failure conditions involving validation, processing, authentication or dependent services.

05

Inspect the complete response Review status code, response body, headers, cookies and other client-visible information returned by the server.

06

Compare with server-side diagnostics Where authorized, confirm that sensitive diagnostic details are retained server-side rather than exposed to clients.

06 / INFORMATION DISCLOSURES

Information to review

STACK TRACES

Framework exceptions, call stacks, method names and source-code execution paths.

FILESYSTEM PATHS

Absolute server paths, application directories and source-code locations.

DATABASE DETAILS

SQL statements, database names, table names, driver information or connection details.

FRAMEWORK DETAILS

Framework internals, package names, versions or development diagnostics unnecessarily exposed.

INTERNAL HOSTS

Internal hostnames, service names, network addresses or infrastructure identifiers.

CONFIGURATION DATA

Environment settings, configuration values or other deployment information not intended for clients.

DEBUG DATA

Variables, request context, loaded modules or diagnostics intended only for developers.

INTERNAL IDENTIFIERS

Sensitive internal object, service, transaction or infrastructure identifiers.

Example: verbose production error

HTTP response EXAMPLE

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

Application Error

Traceback (most recent call last):

File "/var/www/app/controllers/account.py",
line 184, in update_account

DatabaseError:
connection failed to PostgreSQL server
db-prod-02.internal.example:5432

Query:
SELECT * FROM customer_accounts
WHERE account_id = '10482'

Framework: ExampleFramework 4.x
Environment: production

The error response itself can become reconnaissance

Information such as internal paths, database architecture, framework details and service names can help an attacker understand the application's internal structure and identify additional attack opportunities.

07 / ASSESSMENT

Assessment

Condition	Assessment consideration
Generic application error	Normally acceptable when it provides sufficient user guidance without exposing implementation details.
Validation error	The message may explain what input is invalid, but should not expose internal processing details.
Stack trace exposed	Treat as a security concern because implementation details are disclosed directly to the client.
Internal path disclosed	Assess whether the information reveals meaningful application or infrastructure details.
SQL or database error exposed	Determine whether the response reveals schema, query structure or other sensitive database information.
Correlation identifier only	Normally acceptable if it does not expose sensitive internal information and can be used by authorized operators for server-side troubleshooting.

08 / EXPECTED RESULT

Expected result

Pass condition

Production error responses provide an appropriate user-facing or API-facing error message without exposing unnecessary stack traces, source-code locations, database details, internal infrastructure information or development diagnostics.

Detailed diagnostic information should remain available through appropriately protected server-side logging and monitoring mechanisms.

09 / FAILURE CRITERIA

Failure criteria

Production responses expose stack traces to untrusted clients.

Absolute filesystem paths are unnecessarily disclosed.

Database errors disclose sensitive schema or query information.

Internal hostnames or service infrastructure are unnecessarily exposed through errors.

Debugging information intended for developers is returned to production clients.

Sensitive configuration or environment information is included in client-visible error responses.

Example finding INFORMATION DISCLOSURE

An unauthenticated request that produces an application exception returns a complete server stack trace containing the application's filesystem path, framework implementation details and internal database host information. The response is generated by the production deployment and is accessible to untrusted clients.

10 / REMEDIATION

Remediation

Configure production error handling so that clients receive controlled responses while detailed diagnostic information is retained in protected server-side logging systems.

Recommended approach

Disable framework and application debug modes in production.
Implement centralized exception handling.
Return controlled error responses for unexpected application failures.
Remove stack traces and source-code locations from client-visible responses.
Prevent database driver errors from being returned directly to clients.
Avoid exposing internal hostnames, filesystem paths and service details.
Store detailed diagnostics in protected server-side logs.
Use correlation or incident identifiers where operators need to connect client errors with server-side logs.
Apply consistent error handling across web pages, APIs and background processing interfaces.
Ensure production configuration cannot accidentally revert to verbose development behavior during deployment or restart.

Example controlled response

HTTP response RECOMMENDED

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

{
    "error": {
        "code": "INTERNAL_ERROR",
        "message": "An unexpected error occurred.",
        "request_id": "req-7f91a2c4"
    }
}

Do not put sensitive diagnostics into the request ID

Correlation identifiers should be opaque references that allow authorized operators to locate server-side diagnostics. They should not encode database names, usernames, filesystem paths or other sensitive information.

11 / VERIFICATION

Verification

01

Repeat the original error condition Reproduce the same controlled failure that previously generated verbose information.

02

Inspect the client response Confirm that stack traces, source paths, database details and other unnecessary implementation information are no longer returned.

03

Verify server-side diagnostics Confirm that authorized operators can still obtain sufficient diagnostic information from protected application logs or monitoring systems.

04

Verify multiple error paths Test representative validation, authorization, missing-resource and unexpected-failure paths rather than checking only one endpoint.

05

Verify API consistency Confirm that API responses do not expose verbose framework or database errors through alternate content types or endpoints.

06

Verify production configuration Confirm that debug and verbose-error settings remain disabled after the normal deployment, restart and configuration-loading process.

PASS

Production errors are controlled and detailed diagnostics remain available only through appropriately protected operational channels.

FAIL

Production clients can obtain unnecessary internal implementation or diagnostic information.

NOT TESTED

Error behavior could not be adequately reproduced or evaluated.

12 / EVIDENCE

Evidence requirements

Request or action used to trigger the error

HTTP status code

Relevant response body

Relevant response headers

Specific information disclosed

Security relevance of the disclosure

Remediated response

Server-side diagnostic evidence

Post-remediation verification

Final PASS / FAIL determination

Never publish real sensitive error data

Error responses can contain credentials, tokens, personal information, internal addresses and other sensitive data. Evidence intended for a public WebOTG tutorial must use sanitized examples or appropriately redacted captures.

13 / CLASSIFICATION

Classification

WebOTG procedure	WebOTG-SM-024
OWASP category	A02:2025 — Security Misconfiguration
Procedure type	Production error-handling and information-disclosure review
Assessment result	PASS / FAIL / NOT TESTED
Finding severity	Determine from the sensitivity, usefulness and exploitability of the information disclosed.

WebOTG classification notice

WebOTG-SM-024 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 information disclosure and error handling.
OWASP Application Security Verification Standard	Verification requirements relevant to secure error handling and information exposure.
Vendor framework documentation	Defines production error-handling and debugging configuration requirements.
Organization security baseline	Defines approved production logging, monitoring and client-facing error behavior.

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.