Description
Spring Boot error responses containing exception messages, stack traces, binding errors or internal paths can reveal application structure and validation failures. Minimize error details in production responses.
Potential impact
- Exposure of class names, paths, queries and internal state
- Information that helps attackers refine inputs or automate attacks
- Disclosure of sensitive exception messages
Remediation
- Restrict messages, stack traces, binding errors and exception types in production responses. Spring Boot 3.x uses the
server.error.*properties below; check the correspondingspring.web.error.*properties in Spring Boot 4.x. - Return generic messages and tracking IDs in custom errors.
- Keep necessary details in access-controlled server logs, removing passwords and tokens. Check that custom error handlers do not return details independently of these settings.
Examples
These settings apply to Spring Boot 3.x default error responses. Inspect actual responses and apply the same information-minimization principle to custom responses.
Before
properties
server.error.include-message=always
server.error.include-stacktrace=always
After
properties
server.error.include-message=never
server.error.include-stacktrace=never
server.error.include-binding-errors=never
server.error.include-exception=false
Explanation:
- Before: Always includes messages and stack traces in default error responses.
- After: Excludes the specified detailed attributes from default error responses. It does not sanitize error bodies returned by separate controllers.