Attackers Replay Firebase App Requests to Bypass Weak Security Rules

The Firebase configuration compiled into a mobile app is often handled as if it were a secret. A dev.to article by Vaibhav Shakya argues the opposite: that configuration was designed to be public, and the real trouble starts when production systems treat it, a signed-in user, or the app's own interface as proof of permission.

The client is not the boundary

According to the article, an attacker who pulls the Firebase configuration out of an Android or iOS build can recreate legitimate API calls from any script or tool. Hidden buttons, navigation guards, and client-side validation never run in that context, so if Firestore Security Rules or Storage permissions are permissive, the underlying records are reachable no matter what the app's interface appears to restrict.

That is the core failure mode the post describes: the UI implies limits that the backend never actually enforces.

Being signed in is not being authorized

The rule pattern the author singles out is checking only that request.auth is non-null — effectively asking "is anybody logged in?" That confirms an identity exists but says nothing about whether that identity:

• owns the record being requested
• belongs to the correct tenant or account
• is allowed to touch sensitive fields
• may carry out the business transition being attempted

Genuine authorization, the article argues, has to tie the authenticated identity to the specific resource and the specific operation.

App Check is a signal, not a decision

Firebase's App Check attests that a request probably came from a legitimate build of the app. The dev.to post positions it as one layer among several: it raises confidence in the calling environment but does not verify ownership, define roles, or make client-supplied payloads trustworthy. The layered model the author recommends divides the work — authentication answers who, Security Rules decide which data, App Check adds context about the app, and a trusted backend enforces business rules.

High-impact operations belong on the server

The article names operations that should never be driven purely by client writes to the database: settlements, refunds, KYC approvals, administrative role assignment, and reward issuance. For these, a server-side component should validate the actor, the current state of the record, whether the requested transition is permitted, the input itself, and an idempotency key. It should also cope with concurrent requests, retries, replay attempts, and partial failures without carrying out the same business action twice — the classic double-refund scenario.

Security Rules deserve production treatment

Rules, storage permissions, backend identities, and function configuration merit the same engineering discipline as application code, according to the post. In practice that means:

• keeping them in version control with reviewed deployments
• test cases covering cross-user access and unauthenticated access
• field-level validation inside the rules
• least-privilege permissions for backend service identities
• rate controls and caps on how much a single operation can do
• runtime monitoring together with an incident procedure

Monitoring and budget alerts are described as useful for visibility, but not as a substitute for correct authorization or application-level limits.

Why it matters

Firebase's developer experience makes it remarkably easy to ship an app where the client talks straight to the database, with the only real access control being a rules file written once during prototyping. Because the configuration inside the app is readable by design, any gap between what the interface suggests and what the rules enforce is effectively a public API for anyone willing to script against it. The article's closing posture applies well beyond Firebase: assume the client can be inspected, modified, and automated, and put the actual protection at the data and business boundaries where those assumptions stop mattering.