That is one thing that RFC8959 is intended to solve. If you see "secret-token:" in any logs after running tests you flag that as a problem and fail the test.

Thanks I assumed someone else must've had the same idea.

I agree it should be this simple, but I'd bet they have tests like this and unfortunately it's never quite this simple in a production system.

I've always wanted to apply strong type systems to this problem – wrapping sensitive data in types that do not have the ability to be printed to logs would theoretically allow you to know after type-checking that passwords can't be output to logs. However again I think this is wishful thinking as a password needs to be sent somewhere at some point, and that creates places where issues can occur.

Well it's their choice to ask the user to send a plain-text password.

There are alternatives to avoid this, on the same model of SSH key authentication where the secret stays on the client-side.

Nothing prevents them from using a password to derive a private key using PBKDF2 in client-side and answer to a specific challenge.

That's kind of how I've always solved it at the smaller companies I've worked at. I'm on Hacker News all day and know all about these kinds of footguns so I write all the auth code myself and then provide a couple of helper functions/methods for the team to use that are unable to do anything too silly. Creating an object that throws an exception when you try to get it as a string or print it though is something I'll have to try next time.

I've worked on a service that handled credentials where we added tests like this to try to catch if a log statement gets added containing the username/password. We used a few end to end tests rather than attempting to include something like this is the unit tests for every function.

Our tests would set up the app's full context, get a hook into the logging framework to watch for log statements, then make requests to the service containing a set of dummy credentials, like { username: "foo", password: "bar" }. If a log statement containing "foo" or "bar" was detected the test failed.

It's not going to catch every type of issue, but at least some potential footguns can be preventing this way.

That gives me an idea. Create a decorator or otherwise wrap the logging function as you build the apps test context, and feed it a list of sensitive strings you want to detect. Then each time as logger is called have it assert that all those strings are not within the log message.

This way it would blow up on the test that is leaking the credential so you could track it right down and it would transparently apply to all current and future unit tests without any more effort.