> having a mechanism that provides detailed logs—including the POST bodies passed to the API—is invaluable.
He includes a caveat later to avoid logging PII, but this should have a flashing red warning sign attached.
He includes a caveat later to avoid logging PII, but this should have a flashing red warning sign attached.
Or is there more there than authorization that I should be thinking about?
(Obviously I'm not talking about logging cleartext passwords, which don't belong in the database either.)
Unless there is a valid use case for logging PII (and I can’t think of any which can’t be engineered around) then I think it’s best to avoid it in principle.
I think of it as the same as logging passwords, keys or tokens.
Second is potential for DDoS (either intentionally or unintentionally).
Third is possibility of "oopsies" via me intentionally or unintentionally including my passwords/sensitive info/what have you in the POST body. Now you have to add branch to look for and scrub sensitive info in your logger -- otherwise my PII has now been logged (and if I were a massive asshole looking for a quick payday, I could throw up a fuss).
It's fine in dev, but shouldn't be in prod. Too much liability.
(* or 'does its best' to remove PII; I feel like there's an immovable object / unstoppable force thing if the answer is "0% PII _ever_!" because that conflicts with the need to log as many things as you can)
Applications should have a logging interface that can identify and conceal sensitive information, and data stored in the app/database/etc should have a type that can be denoted as sensitive. You will eventually also want to reduce the amount of logs you generate, so it's useful to have logging levels the same way operating systems do.
This is indeed a very tricky process, but we have it close enough to make regulators happy. Most of our log information is stored in SQLite and XML, so we can do a lot of parsing magic to achieve determinism.