TL;DR
Firebase is backed by Google's security infrastructure, but like Supabase, the most common issues are misconfigurations. Open security rules are the #1 problem, allowing anyone to read or write data. Firebase is safe when you write proper security rules and validate data. The platform is secure; your rules determine actual security.
What is Firebase?
Firebase is Google's app development platform offering Firestore (NoSQL database), Realtime Database, Authentication, Cloud Storage, and Cloud Functions. It's one of the most popular backends for mobile and web apps.
Our Verdict
What's Good
- Google's infrastructure
- Built-in auth system
- Security rules system
- SOC 2 / ISO 27001
- App Check for abuse prevention
What to Watch
- Open rules in development
- Complex rule syntax
- No server-side enforcement
- Easy to expose data
- Hard to audit rules
The Security Rules Problem
Critical: Firebase projects often launch with development security rules like "allow read, write: if true;" which means anyone can read and modify all data. This is the most common Firebase security issue.
Why This Happens
- Development mode allows all access
- Developers forget to update before production
- Security rules syntax is complex
- AI-generated apps often skip rules
Common Firebase Vulnerabilities
| Issue | Risk | How to Fix |
|---|---|---|
| Open security rules | Critical | Write restrictive rules |
| No auth validation in rules | High | Check request.auth |
| Missing data validation | High | Validate in rules |
| Storage rules too permissive | Medium | Restrict by path/user |
| Admin SDK key exposed | Critical | Keep server-side only |
Writing Secure Rules
Firestore security rules should follow these principles:
- Deny by default: Start with no access, then allow specific actions
- Validate auth: Always check request.auth for protected data
- Validate data: Check data types and constraints in rules
- Limit scope: Users should only access their own data
Tip: Use the Firebase Emulator Suite to test your security rules locally before deploying. The Rules Playground in the console also helps test specific queries.
Firebase vs Supabase Security
| Aspect | Firebase | Supabase |
|---|---|---|
| Security model | Security Rules | Row Level Security |
| Rule language | Custom DSL | SQL (Postgres policies) |
| Default security | Open in dev mode | Open (no RLS) |
| Testing tools | Emulator, Playground | SQL client |
| Server validation | Cloud Functions | Database triggers |
App Check
Firebase App Check adds another layer of security:
- Verifies requests come from your app
- Protects against abuse and scrapers
- Works with web, iOS, and Android
- Should be used with (not instead of) security rules
Is Firebase safe for production?
Yes, when properly configured. Firebase runs on Google's secure infrastructure and is used by major apps. The security risk is in your configuration, not the platform itself.
::faq-item{question="Why are my security rules "insecure"?"} Firebase warns when rules allow open access. This is appropriate for development but dangerous for production. Write rules that check authentication and limit access to appropriate data. ::
Can hackers access my Firebase config?
Your Firebase config (API key, project ID, etc.) is public by design, like Supabase's anon key. Security comes from your rules, not from hiding the config. The config only identifies your project; rules control access.
Should I use Cloud Functions for security?
Cloud Functions add server-side validation, which is useful for complex logic. However, they don't replace security rules. Use both: rules for access control, functions for business logic validation.