Runtime environment variables which may have secrets is exposed in developer consoler

[mkothapalli418]

Hello Team,

This Package perfectly works and so easy to integrate the runtime variable configuration, but I noticed that all the variables are exposed in developer consoler like below screenshot. Is there a better way to handle that part because it will be security threat to show some sensitive info in developer tools.
`
window.RUNTIME_CONFIG

{REACT_APP_SUPPORT_API: 'https://test.com', REACT_APP_EVENTS_API_ENDPOINT: '/api/Events', REACT_APP_EVENT_INSIGHTS_ENDPOINT: '/api/EventInsights', REACT_APP_EVENT_LOGS_ENDPOINT: '/api/Events/EventLogs', REACT_APP_RUM_EVENTS_ENDPOINT: '/api/Events/GetRUMEvents', …}
`

[kHRISl33t]

Hey!

Thank you, I'm glad you like it! :)

I would like to start with this:

You should never store sensitive information (private keys, etc..) in a front-end application. Those can be read and easily extracted. No matter if you use process.env or the window object. I wouldn't count API_URLs and stuff you mentioned sensitive. Most of this can be checked via the network tab too.

If you want to be ultra-secure, use your backend to send sensitive information back to your application after a successful login.

To clarify the usage or the existence of the package:

The process.env.REACT_APP_... variables are read during the build process, not at serve time. That's why we thought it would be awesome to store these variables on the window object instead of process.env because this way, with a script, it can be easily modifiable after the build.

This package works because it modifies the variables on window.RUNTIME_CONFIG.... at start-time after the build process.

You can't achieve the same with process.env because you will need to rebuild your whole application if you want to change an environment variable.

[gsantosoliver]

Hey!

Thank you, I'm glad you like it! :)

I would like to start with this:

You should never store sensitive information (private keys, etc..) in a front-end application. Those can be read and easily extracted. No matter if you use process.env or the window object. I wouldn't count API_URLs and stuff you mentioned sensitive. Most of this can be checked via the network tab too.

If you want to be ultra-secure, use your backend to send sensitive information back to your application after a successful login.

To clarify the usage or the existence of the package:

The process.env.REACT_APP_... variables are read during the build process, not at serve time. That's why we thought it would be awesome to store these variables on the window object instead of process.env because this way, with a script, it can be easily modifiable after the build.

This package works because it modifies the variables on window.RUNTIME_CONFIG.... at start-time after the build process.

You can't achieve the same with process.env because you will need to rebuild your whole application if you want to change an environment variable.

Ok, considering all that to be truth, can't you please add an option to not to print the variables value in the console? Thanks.

[kHRISl33t]

Ok, considering all that to be truth, can't you please add an option to not to print the variables value in the console? Thanks.

What do you mean by that? I cannot disable users running console.log commands in the developer console.

Please read the CRA docs if you do not believe me. Or any front-end security-related article out there.

WARNING: Do not store any secrets (such as private API keys) in your React app!
Environment variables are embedded into the build, meaning anyone can view them by inspecting your app's files.

[gsantosoliver]

I meant, everytime the application starts, by default, there are print statements on the server console from the runtime-env-cra library, just like shown in the first message in this topic. So, it would be nice to not.to have that in the logs...

[dmitrigrabov]

Reduced console logs would be great. Let me know if you are happy to receive a pull request

[kHRISl33t]

No problem. I'm planning to upgrade everything in the package anyway during the next week.
So sure, I can create a flag that can disable logging of the parsed env variables.

[kHRISl33t]

Just a short status update:

• I finished the changes and made many other improvements based on other pull requests
• The only remaining thing is to finish the tests and documentation, which hopefully I can finish shortly :)