Guide
Denial of wallet: how attacks run up your Firebase bill
October 21, 2026 · 5 min read
On a pay-per-use backend an attack doesn't take your app down, it makes it expensive. Why Firebase apps are exposed and how to shrink the risk.
What is a denial of wallet attack?
A denial of service tries to take your app down. A denial of wallet tries to make it expensive: on a serverless, pay-per-use backend like Firebase, the infrastructure scales to absorb the traffic, and you pay for every read, invocation and gigabyte it serves. The app stays up; the bill is the damage.
It doesn't even need an attacker. A bug that reads a collection in a loop, or a leaked AI API key, produces exactly the same bill.
Why Firebase apps are exposed
- Clients talk to the database directly. Your Firestore or Realtime Database is reachable from any browser that has your config. Security rules decide what it may read; they don't decide how often.
- Even empty answers cost. Firestore charges "a minimum charge of one document read for each query that you perform, even if the query returns no results", and reads needed to evaluate your rules are billed too (Firestore pricing).
- Public files are public bandwidth. A popular or scraped file in Cloud Storage or Hosting bills egress on every download.
- Functions scale by default. Without a max instances setting, a flood of requests is a flood of instances.
How to reduce the attack surface
- Tight security rules. Only let users read what they need, and never leave a collection open while you "finish later".
- App Check. It helps by "preventing unauthorized clients from accessing your backend resources" for Firestore, Realtime Database, Storage, callable functions and AI Logic. Google is honest that it "prevents some, but not all, abuse vectors" (App Check).
- Limits on what can scale. Max instances on functions and request quotas on APIs turn an unbounded cost into a bounded one (how to limit Firebase spending).
- Protect API keys that cost money. Restrict keys by API and by app, and never ship an unrestricted AI key in a client.
And when prevention fails
Prevention lowers the odds; it doesn't make them zero. The last line is noticing fast and acting without a human in the loop. Budget alerts are too slow for that (here's why), so look at usage instead: reads, invocations and bytes downloaded reach Cloud Monitoring in minutes.
That's what FireShield's usage spike detection does on Pro and Enterprise: it compares each watched service's last hour with the same hour over the previous week and, past the multiplier you set, alerts you, triggers a Soft Kill or, if you chose it, disconnects billing.
