Following the changes for #21437, potentially sensitive data including request params / form data may be logged at DEBUG level, and headers at TRACE level.
The initial approach implemented was to log such data at DEBUG and TRACE level by default along with a loud warning on startup and a flag to disable such logging. However the warning is only useful in the beginning and creates a lot of noise on every startup Ultimately it cannot effectively help avoid potential issues when running in production.
The current thinking is to log at DEBUG and TRACE level still, by default but use slightly different output that shows the data is there but masked, along with a flag to enable showing it, and a toned down log message on startup.
For example on startup:
enableLoggingRequestDetails='false': request parameters and headers will be masked to prevent unsafe logging of potentially sensitive data
Then at runtime:
GET "/myPath.do", parameters={masked}, headers={masked}
Rossen Stoyanchev opened SPR-17029 and commented
Following the changes for #21437, potentially sensitive data including request params / form data may be logged at DEBUG level, and headers at TRACE level.
The initial approach implemented was to log such data at DEBUG and TRACE level by default along with a loud warning on startup and a flag to disable such logging. However the warning is only useful in the beginning and creates a lot of noise on every startup Ultimately it cannot effectively help avoid potential issues when running in production.
The current thinking is to log at DEBUG and TRACE level still, by default but use slightly different output that shows the data is there but masked, along with a flag to enable showing it, and a toned down log message on startup.
For example on startup:
Then at runtime:
Affects: 5.0.7
This issue is a sub-task of #21485
Referenced from: commits 1b1bc7f
The text was updated successfully, but these errors were encountered: