Objective
Verify that application error handling provides appropriate information to legitimate users without unnecessarily disclosing implementation details, internal infrastructure information, debugging output or sensitive data.
Error responses are an important part of the application's security boundary. Improperly configured error handling can reveal framework details, filesystem paths, database information, internal hostnames, stack traces, configuration values or other implementation details.
The assessment should distinguish between useful application-level error information and information that materially assists an attacker in understanding or targeting the underlying implementation.
A technical message is only a meaningful security finding when its disclosure creates a relevant security or privacy risk. Avoid raising findings solely because an error response contains ordinary diagnostic wording.
Scope
Review error behavior generated by:
Prerequisites
| Authorization | Confirm authorization to submit invalid or malformed requests to the target application. |
|---|---|
| Application architecture | Understand the application's major components and error-handling layers where possible. |
| Environment | Determine whether the target is a development, testing, staging or production environment. |
| Logging access | Where authorized, access server or application logs to compare client-visible errors with internal diagnostic records. |
Methodology
Generate controlled error conditions and analyze the resulting response. The goal is to determine what information is intentionally exposed to the client and whether sensitive diagnostic information is improperly transferred outside the intended trust boundary.
| Review | Purpose |
|---|---|
| HTTP status | Determine whether the response uses an appropriate status code for the condition. |
| Response body | Identify stack traces, framework errors, internal paths and implementation details. |
| Response headers | Identify server, framework or debugging information unnecessarily disclosed. |
| Error consistency | Determine whether errors are handled consistently across application layers. |
| Environment behavior | Determine whether production uses development-oriented error handling. |
Test procedure
Error categories
| Error type | Review focus |
|---|---|
| 4xx client errors | Confirm that responses provide useful application-level information without exposing implementation details. |
| 5xx server errors | Verify that internal exception details are not returned to clients. |
| Framework exceptions | Check for framework names, versions, stack traces and source locations. |
| Database errors | Check whether SQL statements, schema information, database hostnames or driver details are exposed. |
| Filesystem errors | Check for absolute server paths, filenames and deployment structure. |
| Debug pages | Check for interactive debugging tools, environment variables and application internals. |
| Proxy errors | Check whether upstream infrastructure exposes internal service names, addresses or implementation details. |
Example insecure response
HTTP 500 response contains a full stack trace, internal filesystem path, framework details and database exception information.
HTTP 500 response returns a generic application error and a correlation identifier while detailed diagnostics remain server-side.
HTTP/1.1 500 Internal Server Error
Content-Type: application/json
{
"error": "An unexpected error occurred.",
"request_id": "7f21c4..."
}Assessment
| Condition | Assessment consideration |
|---|---|
| Generic application error | Normally appropriate when internal diagnostics remain server-side. |
| Detailed but non-sensitive message | Determine whether disclosure creates a meaningful security impact. |
| Framework information | Assess whether the information materially assists fingerprinting or exploitation. |
| Stack trace | Determine whether source locations, internal paths or sensitive values are disclosed. |
| Credentials or secrets | Treat as a potentially serious information-disclosure issue and assess the exposed secret immediately. |
| Production debug interface | Assess separately where debugging functionality provides interactive access or sensitive application information. |
Expected result
Error responses provide sufficient information for legitimate users and clients to understand the failure while preventing unnecessary disclosure of internal implementation, infrastructure and sensitive diagnostic information.
Detailed diagnostics should remain available through appropriate server-side logging and monitoring mechanisms rather than being returned directly to untrusted clients.
Failure criteria
A production application returns detailed server exception information to the client when an application error occurs. The response reveals internal implementation details that should remain within the server-side diagnostic boundary.
Remediation
Separate client-facing error handling from internal diagnostic logging. Users should receive controlled responses while authorized operators retain sufficient diagnostic information for troubleshooting.
Recommended approach
- Disable development-mode exception pages in production.
- Implement centralized application error handling where practical.
- Return generic client-facing messages for unexpected server-side failures.
- Keep detailed stack traces and diagnostics in server-side logs.
- Ensure sensitive values are excluded from logs as well as client responses.
- Use correlation or request identifiers to connect client errors with internal diagnostics.
- Configure reverse proxies and gateways so their error pages do not disclose internal infrastructure.
- Apply consistent error handling across web pages, APIs and background service interfaces.
- Review error behavior after framework or server upgrades.
- Monitor error responses for unexpected disclosure.
Example server-side handling model
Application exception
|
+----> Internal diagnostic log
| |
| +-- exception details
| +-- stack trace
| +-- request ID
|
+----> Client response
|
+-- safe error message
+-- request ID
+-- appropriate HTTP statusMoving diagnostic information into logs is only appropriate when those logs are themselves protected, access-controlled and handled according to the organization's security and retention requirements.
Verification
Client-facing errors are appropriately controlled and internal diagnostics remain protected.
Material technical or sensitive information remains exposed through error handling.
Error-handling behavior could not be adequately reproduced or verified.
Evidence requirements
Redact credentials, tokens, session identifiers, database connection strings, internal addresses, personal information and other sensitive values from screenshots, response captures and reports.
Classification
| WebOTG procedure | WebOTG-SM-018 |
|---|---|
| OWASP category | A02:2025 — Security Misconfiguration |
| Procedure type | Error handling and information disclosure configuration review |
| Assessment result | PASS / FAIL / NOT TESTED |
| Finding severity | Determine from the nature and sensitivity of disclosed information, exploitability, affected assets and resulting impact. |
WebOTG-SM-018 is a WebOTG-defined verification procedure. The identifier is not an OWASP-defined test identifier.
References
| Source | Relevance |
|---|---|
| OWASP Top 10:2025 — A02 | Security Misconfiguration category. |
| OWASP Web Security Testing Guide | Testing methodology for information disclosure and application behavior. |
| OWASP Application Security Verification Standard | Application security verification requirements relevant to secure error handling. |
| Application framework security guidance | Configuration requirements for production exception handling and diagnostic output. |
| Organizational logging standard | 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.