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?
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?
Sorry for the late reply on this.
Yea, totally agree that it’s really useful. The context here are remarks around the possibilities for attacks as described here xss - Is it safe to rely on Content-Type: text/plain to mitigate malicious javascript execution in response? - Stack Overflow. Vague scenario, but still possible 
As suggested in that link the easiest thing would be to allow disabling the “but got:” part with a boolean. Another suggestion would be that instead of a boolean, a user could provide a String => Option[String] function so they can either disable it or for.ex use GitHub - OWASP/java-html-sanitizer: Takes third-party HTML and produces HTML that is safe to embed in your web application. Fast and easy to configure. to ensure that the content is sanitized.
Good points, thanks! I created Allow not including the received (invalid) value in the error message created by DefaultDecodeFailureHandler · Issue #4496 · softwaremill/tapir · GitHub to track this.
As for sanitization, wouldn’t replacing < with < and same for > be a simple fix?