Handling API Keys in Mobile Apps Safely

Handling API keys in mobile apps is a common pain point for developers. Hardcoding them in the source code or storing them in plain text can lead to security breaches. In this article, I’ll walk through the practical steps to keep your API keys safe, from using server-side proxies to environment variables and key rotation. Let’s cut the fluff and get to what works.

Why API Keys Need Special Care in Mobile Apps

Unlike web apps, mobile app binaries are distributed to users. Anyone can decompile an APK or IPA and extract hardcoded strings. Even obfuscation tools like ProGuard provide only mild deterrence. The key problem is that once your app is on a device, the user has physical control over the binary.

API keys that are embedded in the app become accessible to attackers. They can use your key to make unauthorized requests, rack up bills, or access private data. This is why treating API keys like secrets in a server-side context is not enough. Mobile apps require a different security model.

Never Hardcode API Keys in Source Code

Hardcoding API keys in source code is the most common mistake. Even if you use version control, the key ends up in the Git history. Consider this scenario: you accidentally push a commit with a key, then remove it later. The key still lives in the commit history. Scanning for secrets in Git repos is a cat-and-mouse game.

Instead, use environment variables during development and build scripts. For example, in React Native, you can use libraries like react-native-config to read keys from a .env file. For Flutter, the flutter_dotenv package serves a similar purpose. This keeps keys out of the codebase and allows different keys for different environments.

Use a Server-Side Proxy for API Calls

The safest approach is to never send API keys to the mobile client at all. Instead, proxy API requests through your own backend server. Your server stores the API key and forwards requests to the third-party API. The mobile app only communicates with your server, which authenticates via user tokens or other secure means.

This pattern is common in cloud-native backends. You can implement it with a thin API layer using Node.js, Python, or Go. The proxy server applies rate limiting, logging, and access controls. This also helps if you need to rotate keys — you update the server without pushing a new app version. For more details on securing backend access, see our guide on Secure Your Cloud-Native Backend from Unauthorized Access.

Store Keys Securely on the Client When Necessary

Sometimes you can’t avoid having keys on the device — for example, when using SDKs that require a key at initialization. In such cases, use the platform’s secure storage:

• iOS Keychain — Apple’s hardware-backed secure storage for sensitive data.
• Android Keystore — Similar to Keychain, but requires API level 23+ for full hardware backing.
• Libraries — Use flutter_secure_storage for Flutter or react-native-keychain for React Native.

Combine secure storage with obfuscation to make reverse engineering harder. Split keys into strings, XOR them at runtime, and avoid storing the full key in a single location. Remember, obfuscation is not encryption — it only slows down an attacker.

Implement Key Rotation and Revocation

Regularly rotate API keys to limit damage if a key leaks. Set up automation in your CI/CD pipeline to generate new keys for each build or release. For example, you can use a secret management tool like HashiCorp Vault or AWS Secrets Manager to provision keys dynamically.

When rotating, invalidate old keys through your API provider’s dashboard. Keep a window of overlap where both old and new keys work to avoid service disruption. For mobile apps, push updated keys via a remote config service (like Firebase Remote Config) so users don’t need to update the app.

Audit and Monitor for Leaked Keys

Even with best practices, keys can leak. Use tools to scan your codebase and third-party dependencies for embedded secrets. GitHub’s secret scanning, GitLeaks, and TruffleHog can help. Set up alerts in your monitoring system to detect unusual API usage that might indicate a compromised key.

If you discover a leak, revoke the key immediately and rotate. Update your server-side proxy or remote config to push a new key to clients. Then investigate how the leaked key was used and tighten your processes to prevent recurrence.

Comparison: Key Storage Approaches

Method	Security Level	Complexity	Rotation Ease
Hardcoded in source	Very low	None	Requires app update
Environment variables (build time)	Medium	Low	Requires app update
Secure storage (Keychain/Keystore)	High	Medium	Requires app update or remote config
Server-side proxy	Very high	High	No app update needed
Remote config + secure storage	High	Medium	No app update needed

As the table shows, the server-side proxy offers the best security and rotation ease at the cost of higher backend complexity. For most apps, combining secure storage with remote config strikes a practical balance.

Common Pitfall: Leaking Keys in CI/CD Logs

One often overlooked area is CI/CD pipelines. Build scripts can inadvertently print API keys to console logs or environment dumps. If your CI server logs are accessible to multiple team members or stored long-term, those keys can leak. Always mask secrets in CI/CD logs. Most CI platforms support secret masking: you mark a variable as secret, and the system replaces its value with `***` in logs. For example, in GitHub Actions, define secrets in the repository settings and reference them as `${{ secrets.MY_KEY }}`. In Jenkins, use the “Mask Passwords” plugin. Also, avoid exporting secrets to subprocesses that may log them. Check your pipeline YAML or DSL for accidental `echo` or `print` commands that output environment variables.

Practical Example: Setting Up a Proxy with Firebase Functions

Let’s walk through a concrete example using Firebase Cloud Functions as a server-side proxy for a Flutter app. Create a function that accepts requests from your app, adds the API key, and forwards to the external service. First, store the API key in Firebase’s environment config: `firebase functions:config:set myapi.key=”YOUR_KEY”`. Then write the function:

const functions = require('firebase-functions');
const axios = require('axios');

exports.proxy = functions.https.onCall(async (data, context) => {
  // Authenticate the caller (e.g., check Firebase Auth UID)
  if (!context.auth) {
    throw new functions.https.HttpsError('unauthenticated', 'Login required');
  }
  const apiKey = functions.config().myapi.key;
  const response = await axios.get('https://thirdparty.com/endpoint', {
    params: { api_key: apiKey, ...data },
  });
  return response.data;
});

In your Flutter app, call the function using the cloud_functions package. This approach keeps the API key completely off the device. You also get free authentication and rate limiting through Firebase. The trade-off is cold start latency and a dependency on Firebase. But for many apps, the security gain is worth it.

Takeaway: Make Security a Habit

Handling API keys securely in mobile apps is about process, not just tools. Adopt a mindset of least privilege: never include secrets in the client that aren’t absolutely needed. Use server-side proxies where possible, store necessary keys in platform secure storage, rotate them regularly, and audit your code for leaks. Your users and your backend will thank you.

Frequently asked questions

What happens if I hardcode an API key in a mobile app?

Hardcoding an API key in a mobile app exposes it to anyone who decompiles the app binary. Attackers can extract the key and use it to make unauthorized API calls, potentially incurring costs or accessing private data. It also makes key rotation difficult because you need to push an app update.

Can I use environment variables to store API keys in mobile apps?

Yes, environment variables can be used during development and build time with packages like react-native-config or flutter_dotenv. However, the keys are still embedded in the binary at compile time. This is better than hardcoding but less secure than server-side proxy or secure storage.

How does a server-side proxy protect API keys?

A server-side proxy keeps the API key on your backend server. The mobile app sends requests to your server, which then adds the key and forwards the request to the external API. This way, the key never reaches the mobile client, greatly reducing the risk of exposure.

What are the best practices for API key rotation in mobile apps?

Use a remote configuration service to push new keys to clients without an app update. Automate key generation in your CI/CD pipeline. Keep a brief overlap period where old and new keys both work to avoid service disruption. Revoke old keys promptly after rotation.

Should I use obfuscation to protect API keys?

Obfuscation can slow down attackers but is not a strong security measure on its own. It makes it harder to find keys in decompiled code, but determined attackers can deobfuscate. Always combine obfuscation with secure storage and preferably a server-side proxy.