Information Exposure Through Error Message
ID |
java.information_exposure_through_error_message |
Severity |
low |
Remediation Complexity |
trivial |
Remediation Risk |
low |
Remediation Effort |
medium |
Resource |
Information Leak |
Language |
Java |
Tags |
ASVS50:v16.4.1, CWE:209, NIST.SP.800-53, OWASP:2025:A06, PCI-DSS:6.5.5 |
Rationale
Error messages are an integral part of application development, used to communicate issues in the code to the developers. However, in a production environment, overly detailed error messages can become a security liability. For example, stack traces or database exception messages can disclose information about file paths, internal IP addresses, stack traces, database structure, or library versions, all of which can be exploited if in the hands of a malicious user.
The exposure happens when those details reach whoever sent the request, in the HTTP response. Details written to a server-side log are the recommended remediation, not the flaw, so they are not reported. A stack trace in the response is reported with a higher severity than an exception message.
The risk is the error detail reaching whoever sent the request. This detector reports a caught exception returned in the HTTP response:
-
the value returned by a request handler whose return value is the response body: a Spring
@RestController,@ResponseBodyorResponseEntityhandler, an@ExceptionHandler, a JAX-RS resource method; -
the servlet response writer / stream (
response.getWriter().print(…),response.sendError(…)), includinge.printStackTrace(response.getWriter()).
@GetMapping("/objects/{id}")
public Map<String, String> get(@PathVariable String id) {
try {
return Map.of("object", resolve(id));
} catch (Exception ex) {
StringWriter writer = new StringWriter();
ex.printStackTrace(new PrintWriter(writer));
return Map.of("error", writer.toString()); // FLAW
}
}A stack trace (e.getStackTrace(), ExceptionUtils.getStackTrace(e), or a writer filled by e.printStackTrace(…))
in the response is reported with high severity, as it always reveals file paths, frameworks and code structure. Any
other reference to the exception (e.getMessage(), e.toString()) is reported with the detector’s configured
severity, but only for a catch-all handler (Exception / Throwable) or one catching a platform exception
(SQLException, IOException, a Spring DataAccessException…). A narrow application handler such as
catch (NumberFormatException e) typically carries an application-authored message.
Logging the exception server-side (a logger, e.printStackTrace() to stderr, System.err.println(e)) is not
reported: that is the recommended remediation. Responses inside a debug-only branch (if (debug)) are not reported
either.
Remediation
To remediate instances of information exposure through error messages, the primary action is to limit the detail provided in exceptions sent to the end-user. Consider the following steps:
-
Generic Error Messages: Ensure that user-facing error messages do not reveal detailed system information. Use generic language and avoid technical specifics.
-
Centralized Error Handling: Employ a global exception handling strategy using a framework that standardizes error responses across your applications.
-
Logging: Utilize logging frameworks to log detailed error information securely, ensuring logs do not expose sensitive data.
-
Security Review: Review all instances where exceptions are caught and handled, ensuring they follow the guidelines above, particularly in areas of code that are publicly accessible.
Following these steps reduces the risk of sensitive data exposure through error messages, thereby strengthening the security posture of the application.
In Java, you may use Spring’s @ControllerAdvice or @ExceptionHandler annotations for specialized and controlled error handling from a central location.
Logging frameworks like SLF4J with Logback can be used to log detailed error information securely, ensuring logs do not expose sensitive data.
Configuration
The detector has the following configurable parameters:
-
allow_explicitly_thrown_errorsto allow explicitly thrown errors.
References
-
CWE-209 : Generation of Error Message Containing Sensitive Information.
-
OWASP Top 10 2025 - A06 : Insecure Design.
-
ERR01-J: Do not allow exceptions to expose sensitive information, in SEI CERT Coding Standard for Java.