🤫 Where are you storing your secrets in your mobile projects?
I hope they’re not in plaintext in your source code.
Nearly every mobile project will ship with secrets like API keys from services, webhook URLs, or maybe even some specific seed data you need. Choosing where to store them properly is key (pun intended), as it could potentially cause your company to go bankrupt over a leaked API key that earns a massive bill. Yes, that’s the worst-case scenario regarding billing, as it’s the case with e.g. the Google Maps SDK API key if you haven’t restricted its access to your app domain only.
In backend and web frontend projects, it’s a common practice to store your keys locally in
.env files and load them from env vars in CI. But for mobile, I think that not enough importance is given to storing your keys away from your codebase in plaintext or — worse — in your
Some businesses offer remote secret management services so that you can fetch your secrets from their API during runtime. But some services can’t wait for you to fetch API keys from another service. Sometimes you need them right away during the app launch. Also, depending on how those services implement their authentication, you’ll have a local API key anyway, so you’ll need to think about how to store that, too.
Another way is to obfuscate your app secrets locally.
Arkana is an open-source project I created to obfuscate the secrets used in your codebase.
Arkana uses code generation to provide your app with its secrets. Secrets are fetched from env vars during Arkana runtime (not your app’s runtime), their values are encoded using a salt generated on each run, and source code is generated using the provided keys and the generated encoded values.
During your app’s runtime, the encoded value is decoded so your app can use the values initially stored in your env vars.
This encoding mechanism makes it difficult for attackers to read your secrets in plain text from your app’s binary (for instance, by using unix strings or other tools like stefanesser/dumpdecrypted and Yelp/detect-secrets).
Arkana supports Xcode projects (iOS/macOS) and works with Swift Package Manager, CocoaPods, and local CocoaPods (aka Development Pods). Although it was built with Android support by design, it doesn’t support Android projects just yet.
I’ve written more about this project FAQs on its page itself, so you might want to check it out directly:
Arkana has helped me immensely, and nowadays, I don’t start new projects that need secrets without it. Setting it up takes a few minutes, and it will pass security audits from rigorous top-tier cybersecurity companies (yup!). If you think your company’s app secrets are not so safe, perhaps it’s time to bring this up with your team. 💪
We’re waiting for an eager, community-driven Android contributor to open a PR ✨ to say we officially support both platforms. If that’s you, we can start discussions here. 🤗 If you know someone who could help, I’d love for you to share this project with them!
roger.ml is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.