T09 · Insecure Skill Coding Practices
- Location
references/integration.md:271- Finding
Raw Exception Messages Exposed in HTTP Responses
- Content
View full analysis
Vulnerability Details
File Location:
references/integration.md, lines 271–275
Vulnerability Type: Information disclosure through unsafe exception handling
Risk Level: Mediumjava @ExceptionHandler(Exception.class) public ResponseEntity<Map<String, Object>> handleError(Exception e) { return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR) .body(Map.of("error", e.getMessage())); }Technical Analysis
The recommended global exception handler catches every
Exceptionand returns the raw result ofe.getMessage()to the requesting client. Exception messages are intended for diagnostics and may contain internal filesystem paths, database or query details, internal hostnames, object identifiers, validation internals, or implementation-specific information.Because the handler applies to the broad
Exceptionbase class, it may expose messages from controllers, service components, persistence layers, and third-party libraries. The information returned depends on the exception triggered, but the application has no output filtering or sanitization boundary in this example.Attack Path
- An application implements the documented global exception handler.
- A remote caller submits malformed input or invokes operations likely to produce application errors.
- A controller or downstream component throws an exception containing internal diagnostic details.
- The handler catches the exception and serializes its raw message into the HTTP response body.
- The caller repeats this process across inputs and endpoints to collect implementation details that may assist subsequent attacks.
Impact Assessment
This issue does not directly grant system privileges or authorization bypass. Its immediate scope is disclosure of whatever diagnostic information appears in exception messages. Depending on the underlying failure, that information may reveal application structure, ...[truncated 409 chars]
- Remediation
View remediation
Remediation Suggestions
- Return a fixed, generic client-facing error message rather than
e.getMessage(). - Log full exception details only on the server through structured logging, with controls to prevent credentials, tokens, and personal data from entering logs.
- Generate a correlation or incident identifier and return that identifier to the client so operators can locate the corresponding server-side event.
- Replace the broad
Exceptionhandler where practical with handlers for expected exception classes, assigning appropriate status codes and explicitly controlled response fields. - Keep framework stack traces and detailed error messages disabled in production responses.
- Add tests that trigger representative controller, validation, persistence, and dependency failures and verify that responses contain no internal diagnostic details.
A safer pattern is:
java @ExceptionHandler(Exception.class) public ResponseEntity<Map<String, Object>> handleError(Exception e) { String incidentId = UUID.randomUUID().toString(); logger.error("Unhandled exception; incidentId={}", incidentId, e); return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR) .body(Map.of( "error", "An internal error occurred", "incidentId", incidentId )); }- Return a fixed, generic client-facing error message rather than