A Database With the Front Door Left Open: Misconfigured Firebase Security Rules

Serverless backend-as-a-service platforms have shifted an enormous amount of what used to be server-side authorization logic into a declarative rules configuration that lives alongside the database itself rather than in application code a developer necessarily thinks of as "security-critical." That shift is powerful and genuinely reduces a lot of traditional backend vulnerability classes. It also creates a new one: if the rules themselves are permissive, there's no server-side code standing between an attacker and the raw database at all, because the rules are the entire access control layer, and a mistake there isn't a bug in some endpoint — it's a bug in the only thing enforcing access to everything.

The target, which I'll call Hollow Pine Apps here per their program's terms, is a mobile fitness-tracking application using a Firebase Realtime Database as its primary backend, with the client app talking to the database directly rather than through any intermediate API server.

Why Client-Side Code Can't Be the Security Boundary Here

Decompiling Hollow Pine's Android app and reading through its database interaction code made the architecture clear: the mobile client connected directly to the Firebase database using a client-side SDK, with the app's own project configuration — including its database URL — embedded directly in the APK, as it necessarily has to be for the client to function at all. This is completely ordinary for this architecture pattern, and it means the security model has to live entirely in the database's own rules configuration, since the client-side code itself is fully visible and fully reconstructable by anyone willing to decompile it, exactly as I had.

Testing the Rules Directly, Independent of the App's Own UI

Rather than testing only through Hollow Pine's own app interface, I used the Firebase REST API directly, interacting with the database exactly as the mobile client's SDK would under the hood, but without any of the app's own UI constraints limiting what requests I could construct:

GET https://hollow-pine-app.firebaseio.com/.json

GET https://hollow-pine-app.firebaseio.com/.json

Sent entirely unauthenticated, with no session token or credential of any kind attached, this returned data. Not an error, not an empty response — an actual, substantial JSON payload representing a meaningful portion of the database's structure, immediately confirming the root-level rules permitted read access with no authentication requirement at all.

Mapping the Actual Exposure

The returned structure included top-level nodes for users, workoutLogs, and healthMetrics, and querying each directly, still with no authentication, confirmed the exposure extended through the entire tree rather than being limited to some intentionally public summary node:

GET https://hollow-pine-app.firebaseio.com/healthMetrics.json

GET https://hollow-pine-app.firebaseio.com/healthMetrics.json

This returned health and fitness data — weight entries, heart rate logs, recorded workout details — organized by user ID, for what appeared to be every user of the application, not scoped to any single account at all. No query parameter, token, or authentication header was required to retrieve any of it; the data was reachable to anyone who simply knew, or guessed, the database's own URL, which, given that it was embedded directly in the publicly distributable APK, was trivially discoverable by any party willing to spend a few minutes decompiling the app.

Confirming Whether Write Access Was Equally Open

Read exposure alone is severe, but I also tested whether the same permissive rules extended to write operations, since a database allowing unauthenticated writes represents an entirely different, additional category of risk — data integrity and injection, not merely confidentiality.

PATCH https://hollow-pine-app.firebaseio.com/healthMetrics/test-verification-node.json
{ "testMarker": "research-confirmation-only" }

PATCH https://hollow-pine-app.firebaseio.com/healthMetrics/test-verification-node.json
{ "testMarker": "research-confirmation-only" }

I used a clearly labeled, uniquely named node specifically to avoid any risk of colliding with or overwriting real user data, and confirmed this write succeeded without any authentication — meaning any unauthenticated party could not only read every user's health data, but could also inject, modify, or delete arbitrary data anywhere in the database structure, with no restriction at all.

Removing the Test Data Immediately

I deleted the test node I'd created the moment I'd confirmed the write succeeded, specifically to avoid leaving any trace of my testing in the live, shared database any longer than necessary to document the finding.

The Report

Title: Firebase Realtime Database security rules permit fully unauthenticated read and write access to all user data

Root cause: The database's security rules do not require authentication for either read or write operations at the root level, meaning any party with knowledge of the database URL — trivially recoverable from the publicly distributed mobile app — can read all stored data across every user and write or modify any node in the database structure without any credential at all.

Reproduction: Unauthenticated read requests against the database root and specific data nodes returning complete, multi-user data; an unauthenticated write request confirming the rules permit modification as well as disclosure, performed against a clearly labeled, immediately-deleted test node.

Impact: Complete, unauthenticated disclosure of all users' health and fitness data, combined with the ability for any party to inject, modify, or delete arbitrary data anywhere in the database, with no access control of any kind standing between an attacker and the entire backend.

Fix recommendations:

• Rewrite the security rules to require authentication for all read and write operations by default, with explicit, narrowly-scoped exceptions only for data genuinely intended to be public
• Scope per-user data nodes so that a given authenticated user can only read and write their own records specifically, rather than any authenticated user being able to reach any other user's data once logged in
• Review Firebase's own rules simulation and testing tools as part of the deployment process going forward, since rules misconfiguration of exactly this kind is a well-documented, extremely common failure mode specifically because the default, unconfigured rule set is permissive rather than restrictive

What Happened After

Hollow Pine Apps locked down the database rules to require authentication and proper per-user scoping within hours of the report, treating it as the most urgent possible fix given the combination of a fully open read-write database holding sensitive health information for the entire user base.

Why Backend-as-a-Service Rules Deserve Direct, Dedicated Testing

Any application built on Firebase, Supabase, or a similar backend-as-a-service platform where the client talks directly to the database deserves a direct test of the underlying rules configuration, independent of whatever the client app's own interface happens to expose or restrict — because the client's own UI constraints say nothing about what the actual backend will accept from a request constructed outside that UI entirely. The database's own configuration project identifier is usually sitting in the app binary already; the only real question is whether anyone has checked what it will actually let you do.