Numerous Applications Using Google’s Firebase Platform Leaking Highly Sensitive Data

Numerous mobile applications have been found to expose critical user information through misconfigured Firebase services, allowing unauthenticated attackers to access databases, storage buckets, Firestore collections, and Remote Config secrets.

This widespread issue first came to light when security researcher Mike Oude Reimer published findings on 16 September 2025, demonstrating that approximately 150 different Firebase endpoints in top-ranked mobile apps were accessible without any authentication.

These exposures ranged from user credentials and private messages to high-privilege API tokens, underscoring a systemic weakness in how developers configure Firebase security rules.

In the weeks following the initial disclosure, ice0 analysts identified a surge in automated scanning tools exploiting this vulnerability, with attackers harvesting millions of records in bulk.

These tools rely on extracting Firebase project IDs from app APK files or known naming conventions, then probing various service endpoints for open permissions.

Although Firebase warns developers that test-mode configurations expire after 30 days, many teams extend these insecure rules or inadvertently leave production environments in test mode.

The result is an expansive attack surface that miscreants can exploit with minimal effort, jeopardizing both enterprise and consumer data.

The impact extends beyond trivial resources such as public images or non-sensitive flags.

At scale, exposed storage buckets have contained millions of user ID photos, cleartext passwords, and even AWS root access tokens.

In one instance, a storage bucket belonging to an app with over 100 million downloads was discovered hosting user ID photos, allowing attackers to compile vast identity databases.

Similarly, misconfigured Realtime Databases revealed private chat logs and geolocation information, while Remote Config endpoints exposed private API keys for third-party services.

ice0 analysts noted that many of these leaks went unreported or were dismissed as non-issues until full datasets were downloaded and inspected.

The following section explores the infection mechanism leveraged by scanning tools to enumerate and exploit Firebase services, focusing on APK extraction, endpoint discovery, and unauthenticated data retrieval.

Infection Mechanism: APK Analysis and Endpoint Enumeration

Scanning tools like OpenFirebase begin by parsing Android Package Kit (APK) files to extract Firebase project IDs, API keys, and Google App IDs from the compiled res/values/strings[.]xml and bundled google-services[.]json.

These identifiers serve as the primary inputs for constructing service URLs. For example, to retrieve a Realtime Database, the scanner issues a simple GET request appending [.]json to the endpoint:

curl - s https[:]//PROJECT_ID-default-rtdb[.]firebaseio[.]com/[.]json

If the response returns HTTP 200 OK and JSON content, the database is flagged as public. In cases where the database resides in a different region, the initial request returns a JSON error containing the correct regional endpoint, which the tool uses to reissue the request.

This two-step lookup ensures comprehensive coverage without brute-forcing every possible domain variation.

For Remote Config, scanners extract both the google_api_key and google_app_id from strings[.]xml before constructing a POST request to the Remote Config API:

curl - s - X POST 
  - H "Content-Type: application/json" 
  - d '{"appId":"GOOGLE_APP_ID","appInstanceId":"any"}' 
  "https[:]//firebaseremoteconfig[.]googleapis[.]com/v1/projects/PROJECT_ID/namespaces/firestore[:]fetch"

A successful 200 OK response containing configuration data or secrets confirms unauthenticated access to Remote Config entries.

Some configurations include the NOTEMPLATE error when no config exists, allowing scanners to differentiate between protected and empty endpoints.

By automating APK decompilation with tools like JADX and iterating through Firestore collection names—either extracted from code references or guessed via wordlists—attackers can enumerate public Firestore instances.

A query to a non-existent collection returns an empty JSON array rather than an authentication error, signaling vulnerability without prior knowledge of collection names.

This infection mechanism, combining APK metadata extraction with targeted API calls, highlights how minimal information disclosure can lead to full data leakage. Organizations relying on

Firebase must enforce strict security rules, audit test-mode expirations, and remove hardcoded keys to prevent these automated attacks.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.