Request debug log includes Account SID
pgcd opened this issue · comments
Issue Summary
We have a celery task worker running in a docker container on AWS, with an aws-firelens sidecar.
Without any kind of intentional configuration, twilio.http.http_client.TwilioHttpClient logs all requests to our papertrail stream, which is rather unexpected to say the least; still, a bigger problem is that the request logs contain the account SID (and other PII) which should absolutely not be the case.
Technical details:
- twilio-python version: 6.50.1
- python version: 3.9
Hi @pgcd , Twilio Python client uses a logger, 'twilio.http_client' to log HTTP requests. You should be able to change the log configuration with
twilio_logger = logging.getLogger('twilio.http_client')
twilio_logger.setLevel(logging.WARNING)
This maybe helpful too: https://stackoverflow.com/questions/71496410/can-you-filter-out-personal-details-from-python-twilio-logger
Hi @claudiachua - thank you for the recommendation and suggestion, which I will implement in my specific case.
Regardless, I think it would be a good idea if the client didn't emit dangerous logs in the first place, since not everyone will think of preventing the logs and the information leak (I, for one, didn't even think that would be the case) and I'm not sure what would happen in terms of GDPR compliance to those who don't do that.
Hi @pgcd , thanks for your advice. To better understand the issue here, could you share with us what kind of PII data are being logged? Are you referring to the Request/Payload/Response logs?
E.g.
INFO:twilio.http_client:POST Request: https://api.twilio.com/2010-04-01/Accounts/XXX/Messages.json
INFO:twilio.http_client:PAYLOAD: {'To': '+XXX', 'From': '+XXX', 'Body': 'Hi there'}
INFO:twilio.http_client:POST Response: 201 {"body": "Hi there", "num_segments": "1", "direction": "outbound-api", "from": "+XXX", "date_updated": "Tue, 29 Nov 2022 19:33:51 +0000", "price": null, "error_message": null, "uri": "/2010-04-01/Accounts/XXX/Messages/XXX.json", "account_sid": "XXX", "num_media": "0", "to": "+XXX", "date_created": "Tue, 29 Nov 2022 19:33:51 +0000", "status": "queued", "sid": "XXX", "date_sent": null, "messaging_service_sid": null, "error_code": null, "price_unit": "USD", "api_version": "2010-04-01", "subresource_uris": {"media": "/2010-04-01/Accounts/XXX/Messages/XXX/Media.json"}}
INFO:twilio.http_client:PAYLOAD: {'To': '+XXX', 'From': '+XXX', 'Body': 'Hi there'} INFO:twilio.http_client:POST Response: 201 {"body": "Hi there", "num_segments": "1", "direction": "outbound-api", "from": "+XXX", "date_updated": "Tue, 29 Nov 2022 19:33:51 +0000", "price": null, "error_message": null, "uri": "/2010-04-01/Accounts/XXX/Messages/XXX.json", "account_sid": "XXX", "num_media": "0", "to": "+XXX", "date_created": "Tue, 29 Nov 2022 19:33:51 +0000", "status": "queued", "sid": "XXX", "date_sent": null, "messaging_service_sid": null, "error_code": null, "price_unit": "USD", "api_version": "2010-04-01", "subresource_uris": {"media": "/2010-04-01/Accounts/XXX/Messages/XXX/Media.json"}}
Precisely this part; the various *sid values are problematic but only inasmuch as logging a secret value is problematic. On the other hand, body and to (the latter especially) could be very well seen as GDPR breaches if somebody were to gain access to the logs.
Given I only noticed this happening after moving the code to a docker container in a specific configuration, I have no idea how concerning this might be "in the wild"; still, I feel like logging potential PIIs should be a very intentional choice by the user, rather than a default - in other words, I'd truncate sids, numbers and body unless the user explicitly requires them not to be truncated.
I was able to reproduce the issue where the PAYLOAD and POST Response objects, containing the To, From, and Body values, are being logged with debug logging enabled. This was using the version of the SDK and Python that you specified in your first comment.
Although, the latest version of the SDK (7.15.4) no longer logs either of these objects. I would recommend upgrading to the latest version of the SDK.
Although, the latest version of the SDK (7.15.4) no longer logs either of these objects. I would recommend upgrading to the latest version of the SDK.
Thank you, I'll do that; I guess the issue can be closed?