-
-
Notifications
You must be signed in to change notification settings - Fork 1k
Description
Most exceptions generated by this package inherit from HTTPError. This class holds the associated request as a property. When a request is thrown, the exception details are logged. When using structured logging, the exception is serialized along with it's properties. This means that the request object is also printed as a log, leading to the following log structure:
{
"message": "...",
"timestamp": "....",
"exception": {
"request": {...}
}
}The request object contains both the request body and headers within it, both of which can contain sensitive data that can be security or compliance risks. For example, authorization or api-key headers, or sensitive data in the request body like personal information, card details, or internal proprietary data.
Generally we can't program for all exception types of all external packages in every application, so we have default exception handling at the root of applications that log exceptions in a structured way. Would it be possible to clean up these exceptions even though I know it could be a breaking change. One suggestion, we could expose the request through a method instead of a property? Then the property could become request details that are safe to log?
I'd also be happy to help implement any changes