Affects: \6.0.11
When using Spring's validation and Open Telemetry (agent version 1.25.0) we are seeing the rejected values (personal information) on the event within our spans.
We have a controller advice that prevents this information in the response and logs, however the uncaught exception of the span is the original MethodArgumentNotValidException and contains the rejected value in the message, making its way into the span as an event attribute.
Comment From: rstoyanchev
Can you provide more details on how the response is rendered? By default, Spring MVC will only render a response body for MethodArgumentNotValidException for an RFC 7807 (ProblemDetail) response from ResponseEntityExceptionHandler and for that the message is just "Invalid request content", not the actual value.
Comment From: aaronjamesford
We have a controller advice that prevents this information in the response and logs
There is no issue in the response, as mentioned
The issue is with OpenTelemetry instrumentation - as this is treated as an uncaught exception the exception message ends up as an attribute on the event that's added to the span. This message contains the rejected value
We are currently looking to search & remove this either via a span processor or in the otel collector, although not ideal, as we see no other easy way to get rid of this information.
Comment From: bclozel
@aaronjamesford have you tried raising this to the OTel agent team? We typically do not leak this information with our own observability instrumentation.
Comment From: aaronjamesford
I have not. The assumption was that the issue exists in Spring framework (the exception message) and not in otel agent as it's behaving as expected - the exception is added to the span as an event
Comment From: bclozel
The OTel agent could add the exception type without collecting the actual message.
I believe doing so is likely to leak sensitive information anyway for any Java exception. Java exception messages are not expected to be public from an API perspective.
I would suggest taking this to the OTel agent directly as we can't break this use case for existing applications when this depends on an agent behavior that is out of our control.