[Web] dotenv file variables exposed in plain text in browser developer tools

[DriftingShadows]

The contents of the environment file is available in plaintext via a browser's developer tools under the network tab when using the dotenv package for a Flutter Web project. The contents of the env file is quite sensitive so is this intended behaviour?

[steve-pires]

Any comment on this issue? This is utterly critical. As is, this package should not be used at all.

[hussamDana92]

Any update in this issue.. still library not secure in web

[kendall-lu]

Still need an update on this issue

[java-james]

I would recommend against putting very sensitive data into your .env file for both mobile and web platforms. For any frontend frameworks, including flutter. This isn't unique to web or flutter web specifically. When used in mobile, the .env can still be viewed in the bundle. This is true in flutter, react, react-native etc.

Even if you replace the env variables ahead of time into the code and obfuscate your code those variables are still retrievable via file / bundle inspection. It's just a certain degree of more effort.

.env should be used to host non sensitive data for the front end of your application. Included but not limited to the API endpoints for an environment, build specific policies, feature flags for builds, 3rd party endpoints the app may use, timeout durations, refresh durations.. Non sensitive things that create a variation of your application for different environments.

Operations that involve truly sensitive keys should be proxied through an API call to a service that can securely host and use these values.

From the frontend, you cannot encrypt these variables without exposing the way to decrypt them. I'm interested to hear if we think there is any benefit in some kind of obfuscation weighed up against any performance woes of the approach etc.

[Heech]

@java-james Thank you for the explanation. May I suggest this should be stated somewhere in the readme?

In my use-case I'm considering using this plugin to prevent hardcoding external api keys in my dart files. Having the api keys separated in an external file would easily allow me to use gitignore to prevent it being kept in source control.

[AdeSupriyadi]

17 December 2022

It's still not resolved

[Tandashi]

It's still not resolved

I think there is nothing to resolve since there is no issues that needs resolving. As @java-james stated (https://github.com/java-james/flutter_dotenv/issues/51#issuecomment-1040908470), .env files should not contain any sensitive data when on the web since there is and always will be a possibility to retrieve this information. This is also the case for nearly every other storage possibility regarding web / mobile.

In my opinion, this issue could be closed since as mentioned there is nothing that needs to be resolved.

[bricekk]

Then, what is the use case of this package

[dvdmgl]

I would recommend against putting very sensitive data into your .env file for both mobile and web platforms. For any frontend frameworks, including flutter. This isn't unique to web or flutter web specifically. When used in mobile, the .env can still be viewed in the bundle. This is true in flutter, react, react-native etc.

Even if you replace the env variables ahead of time into the code and obfuscate your code those variables are still retrievable via file / bundle inspection. It's just a certain degree of more effort.

.env should be used to host non sensitive data for the front end of your application. Included but not limited to the API endpoints for an environment, build specific policies, feature flags for builds, 3rd party endpoints the app may use, timeout durations, refresh durations.. Non sensitive things that create a variation of your application for different environments.

Operations that involve truly sensitive keys should be proxied through an API call to a service that can securely host and use these values.

From the frontend, you cannot encrypt these variables without exposing the way to decrypt them. I'm interested to hear if we think there is any benefit in some kind of obfuscation weighed up against any performance woes of the approach etc.

This explanation makes total sense (kind of obvious), but I would recommend to add this comment as a warning into the README.md the same way there is:

Remember to add the .env file as an entry in your .gitignore if it isn't already unless you want it included in your version control.

...that might induce a distracted developer in error about secrets being secret.

[kevtechi]

Then, what is the use case of this package

Endpoint URLs, flags, keys or tokens that are intended for use on the frontend.

Then what you can do is have different sets of the above for each environment configuration (local, dev, staging, prod). Makes it easy to point your frontend towards various environments.

If you are dealing with secrets, they should be on the backend. The backend should then do the work with them and never reveal them to the frontend.

It's normally pretty standard practice since even compiling your frontend code will include them within the code for someone to find.

[LassazVegaz]

@kev-techi I agree. To add a source of truth, Vite also warns developers not to add sensitive information to .env files. We should add that in this library's documentation too.

[masreplay]

Extract .env Android app with "Apk Editor Studio" https://github.com/kefir500/apk-editor-studio?tab=readme-ov-file

instead, you can use

flutter build apk --dart-define=API_URL=https://dev.example.com