I found a surprising use of a string obfuscator in JavaSript. When I compile a JavaScript file to a binary package using @yao-pkg, if this js file contains secret strings, these strings are entirely viewable when you open the binary package in notepad or some similar text software.

Consider a .env variable that looks like this:

In an example api endpoint, these environment variables are being used like this:

During a vite build, since these are static environment variables, these will be replaced with their corresponding environment variable values:

When you transpile this to CJS, and then package that to a binary file, then open it with some kind of text processor, we're able to see the PRIVATE_STRING inside it (in this case, I am using WordPad as opening it using Notepad just crashes it):

This could potentially be an issue if you have API keys, or secret strings that you need to consume in your application. Someone can simply open the binary using a text processor, then scour for some API keys, and you'll be pwned this way.

This is where string obfuscation comes in. When we include a string obfuscator to obfuscate all private variables before building the application, this is what will happen (keep in mind that in this example, I do the obfuscation after converting the codebase from ESM to CJS):

When we build this codebase to a binary file, we are now unable to find this string in the text editor.

When we try searching for the unobfuscated public key, this is what we get.