Is Firebase secure?
If you have just found your Firebase API key in your JavaScript bundle: that is expected, and on its own it is not the problem. The key identifies your project; it does not authorise access to your data. What decides who can read and write is Security Rules — a small language expressive enough to lock things down tightly, and loose enough that a default or a leftover test rule leaves your whole database open without a single error message.
Run a free scan
Get a graded security report for your Firebase app in under a minute.
Why Firebase apps are commonly at risk
- Firebase config (including the API key) is public by design; Security Rules, not the key, protect your data.
- Public by design is not the same as unrestricted: an unrestricted key can still be used against billable APIs, so apply API key restrictions in Google Cloud and consider App Check.
- Test-mode rules (`allow read, write: if true`) are open to the world and easy to forget in production.
- A rule that checks authentication but not ownership lets any signed-in user read everyone’s data.
- Cloud Storage has its own separate rules that are commonly left permissive.
- Rules are hard to reason about, so an intended-strict rule can be effectively open.
Top security risks in Firebase apps
Test-mode rules left in production
High`allow read, write: if true` (Firebase’s test mode) makes your entire Firestore database readable and writable by anyone with your public config.
Auth-only rules with no ownership check
High`allow read: if request.auth != null` lets any authenticated user read every document, not just their own.
Permissive Cloud Storage rules
HighStorage rules are separate from Firestore rules; left open, uploaded files are readable or writable by anyone.
Over-broad write rules enabling data tampering
MediumWrite rules that don’t validate shape or ownership let clients corrupt or overwrite records, including fields like roles or balances.
How to fix Firebase security gaps
Replace test-mode with ownership rules
Scope reads and writes to the owner, e.g. `allow read, write: if request.auth.uid == resource.data.userId`.
Secure Cloud Storage rules separately
Write explicit Storage rules — they do not inherit from Firestore — and default to private with per-user paths.
Validate writes in rules
Use rule conditions to enforce field types and forbid clients from setting privileged fields (roles, entitlements) directly.
Test rules with the emulator
Run the Firebase Rules emulator with unit tests so a change that opens access fails your build instead of your users.
How do you make a Firebase app rank in Google and AI search?
Securing the app is half the job; the other half is being found. AI engines — ChatGPT, Claude, Perplexity — only cite what their crawlers can read.
Server-render if you use Firebase Hosting + a SPA
Firebase-hosted single-page apps are invisible to AI crawlers that don’t run JavaScript. Prerender or SSR your content routes so GPTBot, ClaudeBot and PerplexityBot receive real HTML.
Allow AI crawlers and ship a sitemap
Allow the AI crawlers in robots.txt and point them at your sitemap so answer engines can find your pages.
Add per-route metadata and JSON-LD
Give each route unique head tags and add Organization + WebSite JSON-LD.
Check that AI crawlers are not blocked
ShipReady reports which AI crawlers your robots.txt disallows, and whether your host blocks a GPTBot request outright — the access problems worth ruling out before anything else.
Deep dives: AI assistants are blocked from reading your site·No structured data found
Firebase security: related guides
FAQ
- Is my Firebase API key being public a problem?
- Not by itself. The Firebase config, including the API key, is meant to be public — it identifies your project rather than authorising access to it, and your data is protected by Security Rules. The caveat is that "public" does not mean "unrestricted": a key with no restrictions can still be pointed at billable Google APIs, so set API key restrictions in the Google Cloud console and consider App Check. What to actually go and check is your Security Rules.
- What is the most common Firebase security mistake?
- Shipping test-mode rules (`if true`) to production, which leaves the whole database open, closely followed by auth-only rules with no ownership check.
- Do Firestore rules cover Cloud Storage?
- No. Cloud Storage has its own separate rules. Securing Firestore does nothing for your buckets — you have to write Storage rules too.
- Is there a Firebase security checker?
- ShipReady checks the two Firebase exposures that are visible from outside your app: whether your Realtime Database answers unauthenticated reads, and whether your Storage bucket can be listed without signing in. Both are detected against your live URL, with evidence. It does not read or lint your rules files — for that, run the Firebase Rules emulator with unit tests. The two together cover most of what goes wrong: the emulator proves the rules you wrote behave as intended, and a live scan proves the rules you actually deployed are not leaving the door open.
- How do Firebase Security Rules compare to Supabase Row Level Security?
- They solve the same problem in different places. Firebase Security Rules are a separate rules language evaluated per request, written per collection or bucket, and deployed with your project. Supabase RLS is standard Postgres row-level security — SQL policies attached to tables. The practical differences: Firebase rules are on by default in locked mode but commonly loosened to test mode and forgotten, whereas Supabase RLS is off by default on every new table, so the common failure is opposite. Firebase splits Firestore and Storage into two separate rule sets that do not inherit from each other; Supabase applies one policy model per table but adds a service_role key that bypasses it entirely.
Don't guess. Scan your Firebase app now.
100+ checks. 30 seconds. Free — with an AI-ready fix prompt for every critical and high finding.