T09 · Insecure Skill Coding Practices
Warning
- Location
- references/integration.md:271
- Finding
- Raw Exception Messages Exposed in HTTP Responses## Vulnerability Details **File Location**: `references/integration.md`, lines 271–275 **Vulnerability Type**: Information disclosure through unsafe exception handling **Risk Level**: Medium ```java @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 `Exception` and returns the raw result of `e.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 `Exception` base 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 1. An application implements the documented global exception handler. 2. A remote caller submits malformed input or invokes operations likely to produce application errors. 3. A controller or downstream component throws an exception containing internal diagnostic details. 4. The handler catches the exception and serializes its raw message into the HTTP response body. 5. 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
- ## 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 `Exception` handler 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 )); } ```