From APK to Firebase Tokens: Analyzing a Hardcoded API Key in an Android App

🔍 From APK to Firebase Tokens: Analyzing a Hardcoded API Key in an Android App | by @escoeascape - Freedium Milestone: 20GB Reached We’ve reached 20GB of stored data — thank you for helping us grow! Patreon Ko-fi Liberapay Close < Go to the original 🔍 From APK to Firebase Tokens: Analyzing a Hardcoded API Key in an Android App 🧭 Introduction @escoeascape Follow ~3 min read · April 2, 2026 (Updated: April 2, 2026) · Free: Yes 🧭 Introduction During a mobile application security assessment, I identified a Firebase configuration embedded inside a production Android APK. By reverse engineering the application, I was able to extract a Google Firebase API key and use it to generate valid Firebase Installation authentication tokens. This write-up demonstrates the full process — from APK analysis to token generation — and discusses the real-world security implications of such exposure. 📦 Target Overview Application: EMI World Android App Package: com.example.in.pain🤠 Firebase Project: xxxxx world-4e352 Testing Methodology: Static Analysis + API Interaction 🔬 Step 1 — Reverse Engineering the APK To begin the analysis, I decompiled the APK using apktool: apktool d xxxxx.apk cd xxxxxworld Next, I searched for Firebase-related configurations: grep "google_api_key" res/values/strings.xml 🔑 Extracted Firebase Configuration AIzaSyXXXXXXXXXXXX 1:XXXXXXXX:android:XXXXXXXX emiworld-4e352 xxxxxx-4e352.appspot.com XXXXXXXX 🧠 Understanding Firebase API Keys Firebase API keys are not secret credentials by design . They are intended to identify the application to Firebase services. However, improper configuration or unrestricted usage can increase the attack surface and enable unintended interactions with backend services. 🌐 Step 2 — Validating the API Key To verify whether the extracted API key was active, I performed a simple request: curl "https://www.googleapis.com/discovery/v1/apis?key=API_KEY" 📌 Observation The response returned: API_KEY_SERVICE_BLOCKED This indicates: The API key is valid It is associated with an active Google Cloud project Some services are restricted 🚀 Step 3 — Generating Firebase Installation Tokens Next, I attempted to interact with the Firebase Installations API. curl -X POST \ "https://firebaseinstallations.googleapis.com/v1/xxxxxxx/PROJECT_NUMBER/xxxxxxx" \ -H "Content-Type: application/json" \ -H "x-goog-api-key: API_KEY" \ -d '{ "appId":"APP_ID", "authVersion":"xxxxx", "sdkVersion":"a:xxxx" }' ✅ Response { "fid": "generatedFID", "refreshToken": "long_lived_token", "authToken": { "token": "JWT_TOKEN", "expiresIn": "000000" } } 🔍 Analysis of the Response FID (Firebase Installation ID): Unique identifier for the app instance authToken (JWT): Short-lived token (~7 days) refreshToken: Long-lived token for renewing access Notably, this process did not require authentication , meaning any party with access to the API key and app ID could generate tokens. ⚠️ Security Implications While Firebase API keys are not confidential, this behavior introduces potential risks: Unauthenticated token generation Long-lived refresh tokens Increased attack surface for Firebase services If additional Firebase components are misconfigured, this could potentially lead to: Abuse of push notification systems (FCM) Access to misconfigured databases (Firestore / Realtime DB) Exposure of files via Firebase Storage Manipulation of Remote Config values 🔗 Attack Surface Expansion This finding becomes more impactful when combined with weak Firebase security rules. Example attack chains: API Key → Token Generation → FCM Abuse → Phishing Campaign API Key → Firestore Access → Data Extraction API Key → Remote Config → Feature Manipulation 🛡️ Recommended Mitigations To reduce risk, the following measures are recommended: Restrict API keys to specific Android apps (SHA-1 fingerprint) Rotate exposed API keys Enforce strict Firebase Security Rules Monitor Firebase API usage for anomalies Avoid exposing unnecessary configuration values in client builds 🧠 Key Takeaways Hardcoded Firebase keys are common — but still worth testing Token generation endpoints can be abused if not properly restricted Real impact depends on backend misconfiguration Chaining vulnerabilities is key in bug bounty hunting 🚀 Conclusion This assessment highlights how a seemingly low-risk issue — like a hardcoded Firebase API key — can lead to deeper security implications when combined with accessible backend services. For security researchers, the takeaway is clear: Always go beyond discovery — focus on exploitation and chaining. 👨‍💻 Final Thoughts This type of finding is a great example of how mobile security, API testing, and cloud misconfigurations intersect. If you're into bug bounty hunting, Firebase is a goldmine — provided you know where to look. #bug-bounty #reverse-engineering #penetration-testing #android-security Reporting a Problem Sometimes we have problems displaying some Medium posts. If you have a problem that some images aren't loading - try using VPN. Probably you have problem with access to Medium CDN (or fucking Cloudflare's bot detection algorithms are blocking you).