Firebase Security Rules: How to Check If Your Data Is Exposed

If your AI-built app stores data in Firebase (Firestore or the Realtime Database), there's a specific, extremely common way it can be leaking everything: open Security Rules. It's the Firebase equivalent of the Supabase open-database problem, and it's just as easy to ship by accident and just as easy to fix once you know to look.

The Firebase config in your code is fine. The rules are what matter

Firebase apps ship a config object in the frontend, your apiKey, projectId, and so on. Seeing it in your page source is normal and safe: it only identifies your project, it doesn't grant access. What actually decides who can read and write your data is your Security Rules. So, exactly like Supabase, the exposed config isn't the danger, open rules are.

The "test mode" trap

When you create a Firestore database, Firebase offers "test mode." It's convenient during building because it lets anyone read and write your data, but it's meant to expire after 30 days, and apps constantly ship with it left on. A rule like this means your entire database is open to the public:

allow read, write: if true;

or one with a future expiry date. If you ever clicked "start in test mode," this is the first thing to check.

How to check your Firebase rules

• Open the Firebase console → Firestore Database (or Realtime Database) → Rules tab.
• Look for any rule that allows read or write with if true, or a request.time < timestamp expiry date that hasn't passed. Those are open to everyone.
• Check both databases if you use both, Firestore and the Realtime Database have separate rules.

What safe rules look like

Secure rules tie access to who's logged in (request.auth) and restrict each person to their own data. For a collection where each document belongs to a user:

match /users/{userId} { allow read, write: if request.auth != null && request.auth.uid == userId; }

The principle: every rule's condition should depend on request.auth, never a blanket if true. Write rules per collection, and separately for reads and writes.

Not sure? Check it from the outside

You can work through the list above yourself, and this guide is meant to let you do exactly that. If you would rather have someone look at it, send me your app's address and I will go through it myself before we speak, then tell you what I found in half an hour. It is free, there is no pitch at the end, and if your app is in good shape I will tell you that.

For the wider list, see the how to check Supabase RLS.