# DefaultDecodeFailureHandler and potential XSS on the client side **URL:** \ **Category:** tapir\ **Created:** [November 27, 2024, 9:13am UTC](https://softwaremill.community/t/defaultdecodefailurehandler-and-potential-xss-on-the-client-side/459 "2024-11-27T09:13:13Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![perok](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/perok/32/277_2.png) [@perok](https://softwaremill.community/u/perok)\ **Post date:** [November 27, 2024, 9:13am UTC](https://softwaremill.community/t/defaultdecodefailurehandler-and-potential-xss-on-the-client-side/459/1 "2024-11-27T09:13:13Z")
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](https://github.com/softwaremill/tapir/blob/3a9c49aa2e400adddece9c43c9881683d8a94c1f/server/core/src/main/scala/sttp/tapir/server/interceptor/decodefailure/DecodeFailureHandler.scala#L259-L284) ---
**Author:** ![adamw](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/adamw/32/28_2.png) [@adamw](https://softwaremill.community/u/adamw)\ **Post date:** [November 27, 2024, 4:08pm UTC](https://softwaremill.community/t/defaultdecodefailurehandler-and-potential-xss-on-the-client-side/459/2 "2024-11-27T16:08:18Z")
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? ---
**Author:** ![perok](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/perok/32/277_2.png) [@perok](https://softwaremill.community/u/perok)\ **Post date:** [March 26, 2025, 9:54am UTC](https://softwaremill.community/t/defaultdecodefailurehandler-and-potential-xss-on-the-client-side/459/3 "2025-03-26T09:54:20Z")
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](https://stackoverflow.com/questions/30897884/is-it-safe-to-rely-on-content-type-text-plain-to-mitigate-malicious-javascript/30901746#30901746). 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.](https://github.com/OWASP/java-html-sanitizer) to ensure that the content is sanitized. ---
**Author:** ![adamw](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/adamw/32/28_2.png) [@adamw](https://softwaremill.community/u/adamw)\ **Post date:** [April 8, 2025, 12:25pm UTC](https://softwaremill.community/t/defaultdecodefailurehandler-and-potential-xss-on-the-client-side/459/4 "2025-04-08T12:25:12Z")
Good points, thanks! I created [Allow not including the received (invalid) value in the error message created by DefaultDecodeFailureHandler · Issue #4496 · softwaremill/tapir · GitHub](https://github.com/softwaremill/tapir/issues/4496) to track this. As for sanitization, wouldn’t replacing `<` with `<` and same for `>` be a simple fix?