Error responses and stack traces

Read straight from ErrorProperties.java:

private IncludeAttribute includeStacktrace = IncludeAttribute.NEVER;
private IncludeAttribute includeMessage = IncludeAttribute.NEVER;

Both default to NEVER. Spring Boot’s default error response carries a timestamp, status, error name and path — and no stack trace, and not even the exception message.

That makes this a verify page, and it is worth stating plainly because it is the one place where Spring Boot’s defaults are better than both of its neighbours on this site:

Framework	Default on an unhandled error
Spring Boot	status only — no trace, no message
Django	full debug page if DEBUG=True (default False)
Express	err.stack to the client, because NODE_ENV defaults to development

the fix

# These are already the defaults. State them if you want them enforced
# against a future change, but there is nothing to turn on.
server:
  error:
    include-stacktrace: never
    include-message: never
    include-binding-errors: never

verify it workedRun this in: http response

curl -s https://example.com/path-that-throws | python3 -m json.tool

You should see timestamp, status, error, path — and no trace or message key. Trigger a real exception rather than a 404; the two take different paths.

What to actually look for

The finding is a project that changed these, and the usual reason is debugging:

# The lines to grep for.
server.error.include-stacktrace: always
server.error.include-message: always

include-stacktrace: on-param deserves a note of its own. It returns the trace when the request carries ?trace=true — which means the behaviour is client-triggered, and anyone who has read the documentation can request it. It is a debugging convenience, not a middle setting, and it does not belong in production.

include-message: always looks harmless next to a stack trace, but exception messages routinely carry the thing that failed: a file path, a SQL fragment, a host name, an upstream URL. It is a smaller leak of the same kind.

The one that does leak by default

Whitelabel error pages and JSON error bodies are conservative. /actuator/heapdump is not — see what /env actually shows. If you are auditing information disclosure on a Spring Boot application, the Actuator surface is where to spend the time, not the error handler.

before you ship this

Nothing, if they are already at the defaults.

Turning them off in an environment where developers rely on them removes a debugging affordance. The replacement is structured server-side logging with a correlation id returned to the client, so support can find the trace without the client receiving it.

Related

• Actuator sensitive values — the disclosure surface that matters here
• Express: stack traces in error responses — the same concern, opposite default