DefaultDecodeFailureHandler and potential XSS on the client side

Hey!

The default error handling for DefaultDecodeFailureHandler returns the invalid value in the response[1]. As the Content-Type header is set then this is not a direct XSS vulnerability, but it makes it easier for the client to expose itself to such issues.

Is it worth looking into if the default behavior should not contain the invalid values, or sanitize the content?

[1] tapir/server/core/src/main/scala/sttp/tapir/server/interceptor/decodefailure/DecodeFailureHandler.scala at 3a9c49aa2e400adddece9c43c9881683d8a94c1f · softwaremill/tapir · GitHub

Hm the invalid values are useful, especially when the validation error comes from a field nested somewhere in the body. It then makes it easier to pinpoint the problem.

What kind of sanitization do you think we could do?