☕ Reverse engineering APKs is fun… until you stumble upon production secrets sitting in plain sight.
🧠 TL;DR
While analyzing a publicly available Android APK, I discovered hardcoded Facebook and Google API credentials directly inside the app's strings.xml file. These included a Facebook App ID, Facebook Client Token, a Google API Key, and other sensitive identifiers. This kind of exposure can lead to impersonation, abuse of API quotas, or worse — all by just decompiling the APK.
In this post, I'll walk you through:
- 🔍 How I found the secrets
- 🧪 How I validated they were live
- 🔥 What impact they can have
- 🛡️ How to avoid making the same mistake
📦 Step 1: Decompile the APK
To start, I used Apktool to decompile the Android app and inspect its internal files:
java -jar apktool.jar d target.apk -o output_folder -fThis unpacks the app into a readable folder structure — allowing access to its resources, manifest, and smali code.
🔍 Step 2: Inspect strings.xml
Inside the res/values/strings.xml file, I found the following:
<string name="facebook_app_id">47711************</string>
<string name="facebook_client_token">ab3495bb67f3e*******************</string>
<string name="google_api_key">AIzaSyCc6**********************</string>
<string name="google_crash_reporting_api_key">AIzaSyCc6**********************</string>
<string name="google_app_id">1:16327*******:android:d2f5************</string>
<string name="google_storage_bucket">[redacted].firebasestorage.app</string>🧠 Reminder: Anything hardcoded in strings.xml gets compiled into the final APK and is easily accessible with tools like apktool, jadx, or even grep.
🧪 Step 3: Exploitation (Ethical Validation Only)
✅ Facebook App ID + Client Token
I tested the Graph API to check if the credentials were valid:
curl "https://graph.facebook.com/app?access_token=47711************|ab3495bb67f3e*******************"Result:
{
"category": "Business",
"link": "https://www.[redacted].com/",
"name": "[Redacted]",
"id": "47711************"
}✅ The token was valid and returned the app's metadata. This means an attacker could impersonate the app while making Graph API calls — a serious security risk depending on what endpoints the app has access to.
❌ Google API Key (Properly Restricted)
I also tried checking if the Google API key was unrestricted by using it with Google's Geocoding API:
curl "https://maps.googleapis.com/maps/api/geocode/json?address=New+York&key=AIzaSyCc6**********************"Result:
"error_message": "This API project is not authorized to use this API."✅ Good news: the developer had restricted this API key in the Google Cloud Console. This prevented abuse, even though the key was exposed.
🛡️ How Developers Can Prevent This
❌ Don't do this:
<string name="facebook_client_token">ab3495bb67f3e*******************</string>✅ Do this instead:
- Store secrets server‑side and never embed them in the APK.
- If client‑side access is absolutely required:
- Fetch the secret dynamically at runtime via a secure HTTPS endpoint.
- Obfuscate it using NDK and store it in Android Keystore.
- For Google API Keys, always:
- Restrict by Android package name and SHA‑1 fingerprint.
- Limit usage only to the APIs your app uses.
🔐 Remember: If it's in the APK, it's not a secret.
👨💻 Advice for Bug Bounty Hunters
If you're analyzing APKs in the wild, make sure to:
- Always check
strings.xml,AndroidManifest.xml, and.smalifiles - Look for patterns like
AIza,facebook_client_token, and Firebase URLs - Validate the keys ethically — never perform abusive actions
- Disclose responsibly and redact details in your public writeups
🧠 Final Thoughts
This vulnerability may seem simple — but it's shockingly common in production apps. Even large companies make this mistake.
By reporting it responsibly, you help secure the app and its users. And if you're a developer reading this — now is the time to rotate those secrets and check your build pipeline.
🙌 Respectful Disclosure
The company affected has been notified via responsible disclosure, and all data in this article is redacted to prevent abuse.
— AIwolfie