Is Firebase Safe?
Firebase is safe. The only recurring failure mode is Security Rules · lots of production apps ship with `allow read, write: if true;` because they copied the getting-started snippet and never came back. That single line can leak an entire database.
Known risks
- Wide-open Security Rules · `if true` rules are found in thousands of production Firestore databases. The anon Firebase config is enough to read everything.
- Storage bucket exposure · Firebase Storage rules default to test-mode allow-all for 30 days. Many teams miss the deadline and stay open.
- API key restrictions absent · The `web` API key is meant to be public, but must be restricted by HTTP referrer and API in Google Cloud Console to prevent abuse.
How to make it safer
- Deny by default, allow by claim · Base rule: `allow read, write: if false;` then open specific paths gated on `request.auth != null` and `resource.data.ownerId == request.auth.uid`.
- Set referrer restrictions · In Google Cloud Console, restrict the web API key to your production domain(s) only.
- Audit rules with the simulator · Firebase's rules simulator lets you test as unauth users. If a public read succeeds, you have a leak.
Frequently asked
Is Firebase safe for production apps?
Yes · Firebase powers apps at massive scale. Your Security Rules are the entire security boundary; audit them.
What's `allow read, write: if true`?
The Firebase getting-started rule. It's meant to be replaced before production. Search your `firestore.rules` for `if true`.
Can I scan a Firebase app?
SimplyScan can check public URL surface and configuration exposure, but Firestore rules need a code-level audit.