TL;DR — Key Takeaways
- 150+ apps leaked data via Firebase misconfigs
- Exposed info: passwords, IDs, cloud keys, etc.
- Root cause: test mode left on or bad access rules
- Quokka detects risky misconfigs in app manifests
Firebase misconfiguration overview
Misconfigured components represent a large-scale, long-term data security crisis. In 2019, The Ohio State University published a paper highlighting data leakage in the cloud from mobile apps. In 2022, we identified 609,428 (33.20%) misconfigured Android apps out of 1,853,862 apps from Google Play. Now, years later, an analysis found that over 150 popular apps, some with more than 100 million downloads, are exposing sensitive user data due to misconfigured Google Firebase services. The analysis by security researcher Icex0 included an audit of about 1,200 mobile apps.
Key points from misconfigured Firebase findings:
- Scope of the issue: Around 80% of the audited apps use Firebase. Roughly 150 had permissive or “test mode” configurations that allowed unauthenticated access to data.
- Exposed data: Payment details, login credentials, messages, cleartext passwords, location data, government ID photos, and cloud access keys (AWS, GitHub, OpenAI, etc.).
- Root cause: Developers often leave Firebase in test mode or set overly permissive rules that persist beyond development.
This Firebase misconfiguration incident underscores just how deeply mobile apps are embedded in complex ecosystems—and how easy it is for a single weak link to expose sensitive data. While some integrations lie outside the direct control of developers, many vulnerabilities stem from app-side configurations that can and should be hardened. That’s where proactive security tooling becomes essential.
Quokka leverages a dedicated analysis tool that scans for security-relevant misconfiguration in app manifest files that can leave apps unprotected at runtime. Among many others, an app manifest file declares a variety of important information, including the unique app package name, device versions compatible with the app, app components and their security and access control settings, permissions requested by the app, and configurations necessary for libraries and features needed by the app. A misconfiguration in access control settings could leave sensitive functionality unprotected.
Common misconfigurations Quokka detects & examples
| Misconfiguration Type | Description / Example | Risks / Impacts |
|---|---|---|
| Misplaced elements / attributes | e.g. putting a android:permission under the wrong parent, or putting an attribute under the wrong tag. | This can lead to runtime behavior that the developer didn’t expect; components may be nonfunctional or expose surfaces incorrectly. |
| Missing elements / attributes | e.g. omitting required elements like android:name attribute on a component. | The absence of a required configuration can cause app crashes or failure to respond to intents, or leave ambiguous behavior. |
| Misspelled elements or attributes | Typos like android:nmae instead of android:name or android:permssion, etc. | These typos effectively break those attributes, making them ignored or wrongly parsed. Could disable intended security controls. |
| Wrong attribute value | Setting an attribute to a value of incorrect type (e.g. expecting integer but string) or invalid enumerations. | Could lead to the system ignoring the config, or misinterpreting it. |
| Unexpected elements / attributes | Adding completely unknown tags or attributes that the schema doesn’t allow. | They may be ignored or create inconsistency; sometimes they are leftover artifacts or misapplied configuration from sample code. |
Security / functional issues exposed by misconfigurations
These misconfigurations are not just academic—they open real attack vectors or failure modes:
- Component Hijacking / Unauthorized Access
- If a component (activity, service, receiver) is exported unintentionally (or allowed incorrectly), a malicious app could invoke or hijack that component. This is especially dangerous when internal logic expects calls only from trusted sources. The misconfiguration may grant unintended permission.
- Sensitive Data Leakage / Backup Attacks
- With misconfigured permissions or backup policies, attackers may extract app data or backup data. Sensitive data could be exfiltrated.
- App crashes / broken functionality
- If required elements or attributes are missing or misplaced, the app may fail at runtime—intents might not resolve, components don’t register, or parsing errors crash the app.
- Message spoofing / broadcast misuse
- Misconfigured intent filters or permission settings can allow spoofed messages or broadcasts to reach components in ways the developer didn’t intend.
- App defrauding / security bypass
- In some cases, manifest misconfiguration allows bypass of intended security checks (e.g. custom permissions are misdeclared) or enables malicious actors to exploit logic paths that dev didn’t intend.
- Secret / internal APIs exposed
- If internal APIs or “private” components are accidentally exposed due to misconfiguration, external actors may access them. The manifest is essentially the gatekeeper for component exposure.
- Inconsistency in system behavior or OS assumption violations
- Because Android’s manifest parsing and enforcement is somewhat ad hoc and not fully schema-driven, misconfigurations lead to inconsistencies or gaps between what the dev thinks will happen and what the system does. The authors also mention how AOSP lacks full schema enforcement, leaving room for these anomalies.
Additional insight & caveats
- Root cause is often from developer snippets / copy-paste: Many misconfigurations arise because developers pick manifest snippets from blogs, sample code, or third-party libraries without fully vetting them.
- Temporal / backward-compatibility issues: Some manifest constraints change over device versions; what was permissible in one version may be disallowed or stricter in later ones. So even a “correct” old manifest may become misconfigured later.
- Not all misconfigurations are exploitable: Not every misconfiguration leads to a direct vulnerability. Some are noncritical or lead to degraded behavior.
Quokka’s AI-powered mobile app risk intelligence eliminates mobile security blindspots, such as app-side misconfigurations. We provide complete visibility into app actions, data flows, and potential risks across your mobile ecosystem. Our mobile app risk intelligence can be delivered for apps you build with Q-mast, apps on your employees devices with Q-scout, or integrated into your technology to enhance your offering. To learn more about how Quokka provides visibility into mobile app security, request a demo.
