Exploiting Local Storage: Sensitive data in the source code
Closed this issue · 2 comments
Risk Rating: Medium
Category: Insecure Data Storage
Description: The application stores sensitive configuration values such as Google API keys, API IDs, and Crash Reporting keys in the strings.xml file. This file is part of the app’s resources and is bundled into the APK, making it accessible to anyone who decompiles the app.
Impact: Information Disclosure: Attackers can extract keys by decompiling the APK.
Abuse of APIs: Exposed keys may allow unauthorized access to backend services or third-party APIs.
Quota Exhaustion: Publicly exposed keys can be abused, leading to service disruption or billing issues.
Reputation Risk: Misuse of keys can result in spam, data scraping, or impersonation of your app.
Remediation Recommendation: Avoid storing sensitive keys in strings.xml or other resource files.
These files are not encrypted and are easily accessible.
Use secure storage mechanisms:
Store keys in a secure backend and fetch them at runtime.
Use Android’s EncryptedSharedPreferences or Keystore for runtime secrets.
I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
Hi @AlexMiller998s, thank you for reaching out. As per our docs, the content of the Firebase config file or object is considered public. This includes the app's platform-specific ID (Apple bundle ID or Android package name) and Firebase project-specific values such as the API Key, project ID, Realtime Database URL, and Cloud Storage bucket name. Therefore, it's crucial to use Firebase Security Rules to safeguard your data and files in Realtime Database, Cloud Firestore, and Cloud Storage.
For open-source projects, we generally advise against including the app's Firebase config file or object in source control. In most cases, your users should create their own Firebase projects and link their apps to their own Firebase resources using their own Firebase config file or object.
Additionally, Firebase-related APIs use API keys solely for identifying the Firebase project or app, not for API call authorization (unlike some other APIs). Authorization for Firebase-related APIs is handled separately from the API key, either through Google Cloud IAM permissions, Firebase Security Rules, or Firebase App Check. This is why it's acceptable to include Firebase API keys in your code when they are used exclusively with Firebase-related APIs. Check out this link for more information.
I'll be closing this issue now. Let me know if there's any misunderstanding so we can re-open this issue. Thanks!