Logging variables and objects is convenient. When developing an app, you can use it to explore the data you receive and display information correctly or trigger further processing.
Permalink to heading What’s the problem with
What’s the problem with
You might say client-side scripts are already accessible in the browser, for example, by digging through the js code. Besides, if you end up disclosing sensitive information, maybe the entire architecture is flawed and, as data are not supposed to be transmitted, it’s not your responsibility.
Still, you may bypass the controller’s logic and security (e.g. in the backend processing) by exposing private data, and you cannot rely on other layers blindly.
A robust system can become vulnerable during a miscalculated operation (e.g. server’s migration) or any other modifications in the code base.
Permalink to heading How to avoid unlucky events How to avoid unlucky events
It’s typically the kind of situations where the company would say:
This is not supposed to happen. We could not anticipate such cascade of bad events
While you cannot anticipate everything, an app is secure as long as all layers are. “Unlikely” does not mean “impossible.”
Here are some practical ways to improve the security:
- remove js logs manually: see that post to speed up the operation
- add a custom wrapper for all
console.log, etc, and use some environment variable to enable/disable your helper
- use a NPM package to remove logs automatically at build
- use a custom library instead
- use the browser’s internal debugger (e.g. Chrome dev tools) instead
Permalink to heading Wrap up Wrap up
console.log or any other variants in production is neither relevant for the end-users nor 100% safe. Don’t raise the curiosity unnecessarily.
Hackers love unwanted disclosures. Please remove them.