Is using a JS object stored inside a global variable instead of a .env file secure?

Issue

A couple days ago I was trying to implement environments in my Expo-managed React Native application. I tried using react-native-dotenv module, but I soon encountered a problem regarding the change of the environment variables (the only way for me to change something was editing each and every file where process.env was called).

After some time I gave up and started to implement something that would work similarly:

• My .env file is now an env.ts
• The environment variables are now object properties

export const env = {
    ENDPOINT: 'http://url.com',
}

• To use my environment I import it in my application entry point and set it as a global variable

import { env } from './env'

...

global.env = env;

• I now use global.env instead of process.env

console.log(global.env.ENDPOINT)

Since this is a JS application the code gets sent to the user that requests the page and since my environment is now code I fear that this might have some security implications.

I'm obviously not sending down my google account's password, but if I need to add an api key it's going to be exposed to whomever has enough patience to look for it, isn't it?

If this do have security implications, how do the various dotenv modules handle this? If I need to show a google map I'll have to send the api key either way, won't I? Where would the difference be?

Solution

Whatever the method you use (dotenv, code constant, etc.), your client app will need to know some API keys, which can then be accessed by a motivated enough attacker.

You can try some mitigation measures (typically to load those keys from a server), but they will end up in client memory anyway.

The main advantage of dotenv method v.s. code constant is to make sure not committing such key into your repository, and to facilitate switching between environments that require different keys.

Answered By - ghybs