It’s easy to assume that the most liked packages on Pub.dev are the best options. However, don’t follow the crowd blindly; the “likes” metric can be misleading for developers searching for packages that truly fit their use case. Here’s where this system can fall short, with an example to illustrate.
The Case of flutter_dotenv
When you see a package like flutter_dotenv, you might immediately think of it as the ideal way to handle your app’s sensitive information, such as API keys or tokens. Typically, .env files are added to .gitignore to prevent sensitive data from being tracked by version control. You might be looking for a package for this purpose on pub.dev and you find this, with some promising metrics. But with flutter_dotenv, this isn’t exactly the case.
According to the documentation, sensitive keys like API keys and tokens should not be stored in your Flutter app, as they can be extracted—even if obfuscated. The package’s documentation warns:
Sensitive keys like API keys and tokens should not be stored in your Flutter app. They can be extracted even if obfuscated. This library currently does not obfuscate variables as it may lull the consumers into a false sense of security. Use environment variables on the fronted application for non-sensitive configuration values, such as API endpoints and feature flags.
It is very true and no one should put secrets in client side app. The documentation suggests adding the .env file as an asset in your pubspec.yaml:
- Add the
.envfile to your assets bundle inpubspec.yaml. Ensure that the path corresponds to the location of the .env file!
- Remember to add the
.envfile as an entry in your.gitignoreif it isn’t already unless you want it included in your version control.
If you have ignored that warning before, congratulations you have avoided your .env file being uploaded to version control but successfully shipped it with your app.
To use flutter_dotenv, the .env file needs to be added as an asset, which means it’s bundled with the app at build time. This is not the typical secure .env setup you might expect. Including it in .gitignore may prevent it from being uploaded to version control, but it doesn’t stop it from being shipped in the final app. Anyone who unzips the APK or extracts the app’s content can access it and view all its contents, including any sensitive information you thought was hidden.
There may be other thing than secrets you want to have in your app and also don’t want it to be easily accessible. We can’t hide secrets but still we can make it harder to find and how harder depends on the attacker. There is missing information that should clearly explain the handling of assets instead of focusing on obfuscation-related issues. This can give a false sense of security and user gonna ignore the warning.
I think the maintainer of flutter_dotenv could provide clearer guidance regarding asset handling and the use of the term .env. It would be even better if the term .env had never been used in a client app. Many users may not fully understand how assets are managed and might develop a false sense of security due to the association with .env terminology and the obfuscation warnings.
When choosing a Flutter package always read the readme, package author may have provided information about what to do and what not to do. Also don’t rely solely on the likes count. Instead, consider other factors like GitHub issues, update frequency, and community feedback to ensure the package meets your security and functional needs.
I hope you found this helpful. Thank you for reading! Happy Tihar!