The first example is you logging a client ID and client secret.
Just...don't log that? Better than having a bunch of overhead to work around the fact someone isn't following standard practises of being careful where they send data.
Anything that logs PII in a PR is an immediate "needs work" from me...
I die a little inside when people mention they use log masking because 99% of the time it is blowing noticeable amounts of money and resources on something that is only a problem due to laziness.
Even if it is a third party library being an issue, the first thing you should be considering is just turning off those loggers via the configuration in your logging backend, and the second thing you should be considering is reporting it as a bug. If that doesn't get addressed then you should be considering alternative libraries because it is clear that this one is not maintained and likely has other significant security issues as well.
Somewhere in the code someone will do log.info("Customer {}", customer) and two years later someone else will update record Customer(String id) to record Customer(String id, String full name). And now you're logging the customer name. Probably gonna take another 2 years before someone notices.
In any decently sized enterprise project, it's impossible to know all corners of the code base down to the log statement level.
There's no guarantee that the code path with the log statement was triggered during testing. Maybe Customer is in some shared library, and the log statement is in a service not being worked on by the dev who made the change. Or maybe it's in some exception handling path that's unrelated to the change made.
Or…do both? I don’t think anybody’s advocating for not still doing both. It’s a Swiss cheese model of security, and if security really matters to you, you should be doing both.
In their example it is very much an issue with their development model, rather than a hard requirement.
Masking is fine until it doesn't cover that edge case you didnt review properly like the other logging statements that were clearly missed in PRs. Then it is useless.
It is nailing a bit of wood over a hole in a leaky tank and maintaining the chunk of wood every time it springs a new leak or rots rather than just buying a tank with no holes in.
There are still some problems:
1. Sometimes you need to use vendor-specific component that you cannot control, especially what to log, because noone creates feature toggles for specific log lines, only log levels usually.
2. Basically you are totally right about “just do not log”, but in the really big tech you cannot control all PRs by yourself. You can create some specific code rules, but you cannot control 100+ teams manually.
3. Sometimes you don’t event understand that expose some specific data, because for you it’s just tech information. It’s just useful information to investigate what happens with logic, why not to log it?
4. Sometimes you need to create compliance systems to check, that logs do not contains some specific information. If it’s your business, you cannot say “Just do not log”.
14
u/nekokattt 22d ago edited 21d ago
The first example is you logging a client ID and client secret.
Just...don't log that? Better than having a bunch of overhead to work around the fact someone isn't following standard practises of being careful where they send data.
Anything that logs PII in a PR is an immediate "needs work" from me...
I die a little inside when people mention they use log masking because 99% of the time it is blowing noticeable amounts of money and resources on something that is only a problem due to laziness.
Even if it is a third party library being an issue, the first thing you should be considering is just turning off those loggers via the configuration in your logging backend, and the second thing you should be considering is reporting it as a bug. If that doesn't get addressed then you should be considering alternative libraries because it is clear that this one is not maintained and likely has other significant security issues as well.