NPI Exposed in info log

[brentleeper]

Affects Version(s): <Spring Integration version>
Current

In org.springframework.integration.handler.support.MessagingMethodInvokerHelper.fallbackToInvokeExpression(), the message is logged using LOGGER.info, this should be LOGGER.warn.

Also, this log message currently fully exposes the contents of the ParametersWrapper 'parameters' in the INFO logs and I believe this is undesired, as parameters is exposing its state too openly for this logging level and should be split from the above into LOGGER.debug

[artembilan]

The WARN is a bit lower severity than INFO. That means when you enable INFO for logging you are going to see WARN, too. So, your concern about logging level is not clear.
Also we select a level according some logic: there is no reason to make a WARN here because we are going to do a fallback therefore your program is not going to fail.

The parameter masking is kinda not related to this issue and there are many places where we print messages with their payload and headers.
If you wish we can make this message under DEBUG, but again: is this really only a place where you worry about your data exposure?

[brentleeper]

Leaving the logging level at info for the message is agreeable. However, in my current use case, logging the payload and headers in the info log is exposing NPI in the log file. For now my work around is just to set the logger to off.

[brentleeper]

NPI - Non Public Information

[artembilan]

OK. Understandable.

So, we can treat this issue like:

Whenever we log a content of the message under INFO, consider to move such a possibly sensitive information under DEBUG level, leaving with an INFO just a generic note.

I don't say that we are going to do that because this is not a trivial task and we also throw exceptions in many places with the message caused an error. How to be over here then?

Wouldn't it be better to not have an INFO or DEBUG logging level for the framework and log reasonable messages using your own components ?

[brentleeper]

I understand that this would be a large undertaking. But what you describe above is exactly what I am thinking and we do have logging in our own components.

For now the work around is acceptable, but if there is an issue related to the framework it may be more difficult trace.

[artembilan]

Well, for that reason an issue is going to be logged under ERROR or WARN. In most case of course it is going to be an exception with the whole stack trace to track the reason or so.

[artembilan]

@garyrussell ,

I would like to hear your opinion about this issue.

Thanks

[garyrussell]

Maybe ask Spring Framework to add:

public interface MessageToStringFunction extends Function<Message<?>, String> {
}

and setToStringFunction(MessageToStringFunction function) to GenericMessage and our MessageBuilder can inject a user-supplied implementation into every message. That way the user can obfuscate/remove NPI.

??

[artembilan]

Raised: spring-projects/spring-framework#24727

[artembilan]

Duplicate of #9416