Inquiry Regarding Storage & Sensitive Data Handling in React Native Firebase Modules

[praveen-18m]

Hello React Native Firebase Team,

We are currently performing a security assessment of our mobile application, which integrates React Native Firebase modules.
During a recent static security scan (via Quixxi SAST), two potential issues were flagged across the following modules:

---

Identified Issues & Affected Modules

1. Read/Write Access to External Storage

• ReactNativeFirebaseUtilsModule

2. Cleartext Storage of Sensitive Information

• Firebase Messaging

---

Our questions for you:

1. Regarding FirebaseUtilsModule:

   • Does this module write data to external storage in a way that could expose files to other apps (e.g., using public directories)?
   • Are there best practices or recommended configurations to restrict file access (e.g., using app-specific storage only)?

2. Regarding Firebase Messaging:

   • Does this module store any sensitive information (e.g., tokens, message payloads, metadata) locally in cleartext?
   • If so, are there recommended practices or options to secure/encrypt this data at rest?

3. Do you have documentation or security guidelines clarifying how these modules handle file storage, data access, and sensitive information securely?

Your assistance in clarifying these concerns will help us document secure usage practices and ensure compliance with security standards such as OWASP MASVS.

We are happy to provide relevant scan report excerpts if needed.

Thank you in advance for your support.

[mikehardy]

Hey there 👋

We are happy to provide relevant scan report excerpts if needed.

Would be interesting to see these, I assume they'll point to specific line numbers which can help.

react-native-firebase is multi-platform, and security is pretty specific, so configurations and best practices (and the usage at all, really) is going to depend on what was flagged. Could vary from simply "don't use this API on Android and you're fine" to "configure your iOS app to use encrypted storage until first unlock" or similar, but will vary that widely depending on what the scan was showing

[praveen-18m]

@mikehardy Thank you for the response!

Here are the specific scan findings with line numbers:

1. External Storage Access
Our scan detected .getExternalStorage in io/invertase/firebase/utils/ReactNativeFirebaseUtilsModule.java:

line 118: hashMap.put(KEY_PICS_DIRECTORY, Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_PICTURES).getAbsolutePath());
line 119: hashMap.put(KEY_MOVIES_DIRECTORY, Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_MOVIES).getAbsolutePath());
line 120: File externalStorageDirectory = Environment.getExternalStorageDirectory();

2. Cleartext Storage - Hardcoded Keys
Our scan flagged hardcoded string keys in multiple files:
ReactNativeFirebaseMessagingSerializer.java:

javaline 22: private static final String key_collapse_key = "collapsekey";
ReactNativeFirebaseMessagingHeadlessService.java:
javaline 13: private static final String timeout_json_key = "messaging_android_headless_task_timeout";
TaskExecutorService.java:
javaline 15: private static final String maximum_pool_size_key = "android_task_executor_maximum_pool_size";

Our Questions:

Will these findings affect our app security? Since this is native Firebase code, are these actual security vulnerabilities we need to address?
External Storage: Does the external storage access in ReactNativeFirebaseUtilsModule pose a real security risk, or is this standard Android functionality?
Hardcoded Keys: Are these hardcoded string constants considered sensitive data that could be exploited, or are they just configuration identifiers?
Do we need to take any action on our end, or are these false positives from our security scanner?

We want to understand if these represent genuine security risks requiring mitigation or if they're expected behaviour from the Firebase SDK.

[github-actions]

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.