How many times have you found sensitive information in the logs (like console.log call or actual log files from winston or pino)? Have you ever come across sensitive information such as a user's plain-text password or a database connection string in the logs?

It's very common for Node.js developers to use console.log() as a debugging method. It's easy to add a bunch of console.log statements in your code to see how values of variables change. Unfortunately, it's also common that these logs stay in the codebase, potentially logging things that shouldn't be logged at all.

In this post, I'd like to show you how you can hide sensitive data (like secrets or user passwords) from being logged, whether it's console.log (and its siblings i.e. console.warn or console.error) or any other logger commonly used in Node.js ecosystem.

User password example

Instead of jumping right to the solution, let's work on an example, so you can understand what's going on. We'll use the user password as example of something that we shouldn't log.

Assume we are building a backend application where user can create an account. For that they need to pass in their email and password. The snippet below shows the DTO (Data Transfer Object) that corresponds to the request body of registration endpoint.

interface CreateUserDto {
  email: string;
  password: string;
}

We also have a function (a request handler) that receives the data from the client - the email and password of the user to register.

function registerUser(payload: CreateUserDto) {
  // implementation added later
}

and a function that operates on the database and creates actual user record in the database

function createUserRecord(data: { email: string; password: string }) {
  // implementation not important
}

What could go wrong?

In order to see whether our solution works, we need to set up "tests". In this case, the tests would be different calls to log the incoming data, so that we know that we are covering all cases.

Let's assume the implementation of registerUser function looks like this:

function registerUser(payload: CreateUserDto) {
  // do something with payload, e.g. store in database
  createUserRecord(payload);

  // debugging log in the wild
  console.log('payload:', payload);

  // imagine payload is returned back as JSON
  console.log('stringified payload:', JSON.stringify(payload));

  // try to log password
  console.log('console.log password:', payload.password);

  // try to log password as string
  console.log('password.toString():', payload.password.toString());
}

The snippet above logs the payload or payload.password in four ways:

1. Log whole payload object on line 6
2. Log payload object as JSON (using JSON.stringify) on line 9
3. Log only payload.password on line 12
4. Log only payload.password as string (using .toString() method available on every object in JS) on line 15

This implementation will remain the same for the rest of the post (almost 😉)

When called like this:

const payload: CreateUserDto = {
  email: 'test@gmail.com',
  password: 'my-secret-password',
};

registerUser(payload);

Calling the function results in the following logs:

[LOG]: "payload:",  {
  "email": "test@gmail.com",
  "password": "my-secret-password"
}
[LOG]: "stringified payload:",  "{"email":"test@gmail.com","password":"my-secret-password"}"
[LOG]: "console.log password:",  "my-secret-password"
[LOG]: "password.toString():",  "my-secret-password"

Oof, so many secrets exposed!

Exploring solution

Now that we have set up the example, let's try to hide the user password from the console.log calls.

Create custom class for password

First thing we want to do is to wrap the password (of type string) into it's own type. We can achieve this pretty easily by creating a Password class:

class Password {
  constructor(private readonly plain: string) {}

  expose(): string {
    return this.plain;
  }
}

This way we can have a better control of what the developer can do with our Password class.

We made the plain property private, so that no one else can read it, but made it available through special expose() function.

Ok, we have a class, but it's unused. Let's refactor our DTO to use the new Password class:

interface CreateUserDto {
  email: string;
  password: Password;
}

We also need to adjust the registerUser function to use password.expose() - we need an inner type for call to createUserRecord on line 2.

function registerUser(payload: CreateUserDto) {
  createUserRecord({ ...payload, password: payload.password.expose() });
  console.log('payload:', payload);
  console.log('stringified payload:', JSON.stringify(payload));
  console.log('console.log password:', payload.password);
  console.log('password.toString():', payload.password.toString());
}

When we call the registerUser function with new CreateUserDto like this

const payload: CreateUserDto = {
  email: 'test@gmail.com',
  password: new Password('my-secret-password'),
};

registerUser(payload);

these are the logs

[LOG]: "payload:",  {
  "email": "test@gmail.com",
  "password": {
    "plain": "my-secret-password"
  }
}
[LOG]: "stringified payload:",  "{"email":"test@gmail.com","password":{"plain":"my-secret-password"}}"
[LOG]: "console.log password:",  Password: {
  "plain": "my-secret-password"
}
[LOG]: "password.toString():",  "[object Object]"

So far, nothing has been fixed... unless we count [object Object] as successfully hidden password 😅

Fixing [object Object]

We have achieved a small victory - the password is not exposed when it's logged with use of toString() method!

Unfortunately, it's not very usable in the long run as it returns [object Object], plus toString() isn't commonly used when it comes to console.log.

You might be wondering, where does the [object Object] come from? It's default serialization of an object in JavaScript.

Okay, now we know a little bit more about the toString() topic. Fixing it should be easy, we just need to implement our own toString() for our class.

Let's modify it to return something more meaningful than [object Object]!

class Password {
  constructor(private readonly plain: string) {}

  expose(): string {
    return this.plain;
  }

  toString(): string {
    return '[REDACTED PASSWORD]';
  }
}

Calling the registerUser function now produces logs like this:

[LOG]: "payload:",  {
  "email": "test@gmail.com",
  "password": {
    "plain": "my-secret-password"
  }
}
[LOG]: "stringified payload:",  "{"email":"test@gmail.com","password":{"plain":"my-secret-password"}}"
[LOG]: "console.log password:",  Password: {
  "plain": "my-secret-password"
}
[LOG]: "password.toString():",  "[REDACTED PASSWORD]"

We're are making progress! One of the logs patched, a few more to go.

Hiding secrets in JSON

Now let's tackle the JSON.stringify log.

[LOG]: "stringified payload:",  "{"email":"test@gmail.com","password":{"plain":"my-secret-password"}}"

Based on the log above, we can say that it clearly knows something about private properties in our class - it uses plain property in the output, the same as we have in the class.

When we check the specification 25.5.2.5 SerializeJSONObject, we can see that for each of properties in object's own properties a 25.5.2.2 SerializeJSONProperty algorithm is running, which (similarly to toString) checks whether the object has it's own implementation of toJSON method.

If it's available, then it is being used, otherwise the default algorithm is used which goes through all properties recursively until it reaches any primitive types that is known how to be represented in a JSON.

Therefore, the solution here is to implement toJSON on our Password class. Let's make it simply return the same thing that toString() does to be consistent.

class Password {
  constructor(private readonly plain: string) {}

  expose(): string {
    return this.plain;
  }

  toString(): string {
    return '[REDACTED PASSWORD]';
  }

  toJSON(): string {
    return this.toString();
  }
}

With that implementation, our logs look like this:

payload: {
  email: 'test@gmail.com',
  password: Password { plain: 'my-secret-password' }
}
stringified payload: {"email":"test@gmail.com","password":"[REDACTED PASSWORD]"}
console.log password: Password { plain: 'my-secret-password' }
password.toString(): [REDACTED PASSWORD]

Alright, we have successfully fixed the JSON log - it no longer contains our password. As you can see, there is one more issue left to be fixed - the output of console.log().

Do we have any control over how the console.log prints out objects? Fortunately, yes.

Handling console.log output

The implementation of console.log can vary across different platforms. For instance, it can function differently in browsers, with variations even between Chrome and Firefox, as well as in Node.js.

Why is this relevant here? Thanks to this, the Node.js gives us some room for customizing how objects in our code are displayed with console.log. Let's find out how we can do this.

Upon examining the console.log documentation for Node.js, we find that all parameters passed to console.log are passed to util.format function.

If we dive deep enough into Node.js source code, we can see that util.format() uses util.inspect() under the hood with various options, depending on the format and type of the object being formatted.

We should check how the util.inspect works then!

What is util.inspect?

In Node.js, the util.inspect function serves as a powerful utility for converting JavaScript objects into strings. It provides a way to inspect and represent objects in a human-readable format, which can be useful for debugging, logging and other purposes.

Let's take a look on a basic usage example:

import util from 'node:util';

const obj = {
  name: 'John',
  age: 25,
  city: 'Las Vegas',
};

const objString = util.inspect(obj);
console.log(objString);
// prints
// { name: 'John', age: 25, city: 'Las Vegas' }

It seem to return a JSON representation of the object, so, how is it different from JSON.stringify?

Notice the lack of quotes around the names of the properties - it's not a valid JSON, it's more like you'd put it in the code.

It does handle some cases differently, e.g. circular references:

import util from 'node:util';

const obj = {
  name: 'John',
  age: 25,
  city: 'Las Vegas',
};

(obj as any).selfReference = obj;

const objString = util.inspect(obj);
console.log(objString);

This prints log like this:

<ref *1> {
  name: 'John',
  age: 25,
  city: 'Las Vegas',
  selfReference: [Circular *1]
}

where trying to JSON.stringify such object results in an error

TypeError: Converting circular structure to JSON
    --> starting at object with constructor 'Object'
    --- property 'selfReference' closes the circle
    at JSON.stringify (<anonymous>)

util.inspect also accepts an object of options so you can customize the format of the output.

For example, this code will print the colored output (colors: true) on one line (compact: true) with going at most 1 level deep into nested objects (depth: 1).

import util from 'node:util';

const obj = {
  name: 'John',
  age: 25,
  city: 'Las Vegas',
  object: {
    has: {
      nested: {
        properties: true,
      },
    },
  },
};

const objString = util.inspect(obj, { colors: true, depth: 1, compact: true });
console.log(objString);

Output:

{ name: 'John', age: 25, city: 'Las Vegas', object: { has: [Object] } }

You can read about other options on the util.inspect documentation page.

Changing behaviour of util.inspect for our class

The Node.js team prepared a way for the users of their runtime to customize the behaviour of util.inspect by adding a special function to the objects.

The function should use util.inspect.custom symbol that is registered globally and can be accessed through either Symbol.for('nodejs.util.inspect.custom') or by importing util from node:util package and using it like so: util.inspect.custom.

Let's add that to our Password class and see what happens. We'll make the util.inspect to return (again) the same thing as toString() does.

import util from 'node:util';

class Password {
  constructor(private readonly plain: string) {}

  expose(): string {
    return this.plain;
  }

  toString(): string {
    return '*** Redacted password ***';
  }

  toJSON(): string {
    return this.toString();
  }

  [util.inspect.custom](): string {
    return `'${this.toString()}'`;
  }
}

Let's take a look into the logs after we have the custom implementation for util.inspect

const payload: CreateUserDto = {
  email: 'test@gmail.com',
  password: new Password('my-secret-password'),
};

registerUser(payload);

console.log('util.inspect:', util.inspect(payload));

Output:

payload: { email: 'test@gmail.com', password: '[REDACTED PASSWORD]' }
stringified payload: {"email":"test@gmail.com","password":"[REDACTED PASSWORD]"}
console.log password: '[REDACTED PASSWORD]'
password.toString(): [REDACTED PASSWORD]
util.inspect: { email: 'test@gmail.com', password: '[REDACTED PASSWORD]' }

Note: Wrapping result in apostrophes

I've wrapped the results of toString() method with apostrophes (').

This is not required, I just like the output this way better as it clearly shows that type of value in password field is indeed a string compared with implementation like this:

[util.inspect.custom](): string {
  return this.toString();
}

And output

util.inspect: { email: 'test@gmail.com', password: [REDACTED PASSWORD] }

As mentioned above, this is just a personal preference.

We achieved our goal! We successfully hidden the password from various methods of logging in Node.js.

Extra: Making it more generic

The class we created above works great, but what if we have more sensitive data to keep out of logs than just a password? Copy-pasting the code for each data type we want to hide will be cumbersome. Imagine we would like to change the common behavious (e.g. use some additional options in out util.inspect.custom function) - so many places to refactor!

Abstract class

We can use OOP functionalities of JS/TS and create a base class for other types to extend! Let's call it Secret to be less associated with password.

import util from 'node:util';

abstract class Secret {
  constructor(protected readonly data: string) {}

  exposeSecret(): string {
    return this.data;
  }

  toString(): string {
    return '[REDACTED]';
  }

  toJSON(): string {
    return this.toString();
  }

  [util.inspect.custom](): string {
    return `'${this.toString()}'`;
  }
}

We created an abstract class Secret which is almost 1:1 copy of our Password class from examples above. The only differences are:

• we have a data property instead of plain property
• the expose() method is renamed to exposeSecret()

Now we can refactor our Password class to extend the Secret class

class Password extends Secret {
  constructor(plain: string) {
    super(plain);
  }

  toString(): string {
    return '[REDACTED PASSWORD]';
  }
}

We had to refactor the constructor a bit - we no longer need to keep the plain password inside our class - Secret does it for us.

Lines 6-8 are not required for Password class to work but overriding the toString() method allows us to be more specific what is being redacted from the logs (by default it would use implementation from Secret which would print [REDACTED]).

Supporting other data than string

So far our Secret class allows us to store only string values as the secrets. While this is usually the case, maybe we would like sometimes to keep whole object as a secret?

We can make the Secret class generic over the type of data stored inside!

abstract class Secret<T> {
  constructor(protected readonly data: T) {}

  exposeSecret(): T {
    return this.data;
  }

  toString(): string {
    return '[REDACTED]';
  }

  toJSON(): string {
    return this.toString();
  }

  [util.inspect.custom](): string {
    return `'${this.toString()}'`;
  }
}

We introduced a type parameter T in our class definition. This allows us to pass any type of data into the Secret class and have it type safe (exposeSecret() on line 4 returns the same type as passed in in constructor).

With this definition of Secret class, our Password class looks like this:

class Password extends Secret<string> {
  constructor(plain: string) {
    super(plain);
  }

  toString(): string {
    return '[REDACTED PASSWORD]';
  }
}

Now we extend Secret<string> to narrow down what types can be used in the constructor.

We can now easily create another type of secret, like OpenAIConfig for keeping our API keys safe:

class OpenAIConfig extends Secret<{ key: string; orgId: string }> {}

const config = new OpenAIConfig({
  key: 'my-secret-key',
  orgId: 'my-secret-org-id',
});

console.log(config);
console.log(config.exposeSecret().key);

In this case, our secret data type is { key: string; orgId: string } passed explicitly on line 1.

If we log the config struct, we see the default [REDACTED] message, unless we call config.exposeSecret() which gives us access to the inner data.

Executing code in the snippet above result in logs like this:

'[REDACTED]'
my-secret-key

Conclusion

In this post, we've explored the importance of keeping sensitive information, such as passwords and API keys, hidden from logs in Node.js applications. We've seen how easily such data can be exposed through common debugging practices like using console.log() or other logging libraries.

To tackle this issue, we've introduced the concept of wrapping sensitive data in a custom class, which gives us greater control over how this data is logged. We've created a Password class as an example, which redacts the password when it's logged in various ways.

We've also delved into some of the intricacies of JavaScript and Node.js, such as how console.log(), JSON.stringify(), and util.inspect() handle objects, and how we can customize their behavior by defining methods like toString(), toJSON(), and util.inspect.custom in our classes.

Finally, we've generalized our solution by creating an abstract Secret class that can be used to hide any type of data. This allows us to easily create new types of secrets without duplicating code.

Remember, security is a crucial aspect of software development, and it's our responsibility as developers to protect sensitive data. By being aware of potential pitfalls and knowing how to avoid them, we can make our applications safer and more reliable.

Thank you for reading, and happy coding!