All posts

Field guide

Is my Firebase database open? How to check your security rules

If your app uses Firebase, its config is in the browser, and that is fine. What decides whether your data is safe is your Security Rules, which are easy to leave in test mode. Here is how to check, in a couple of minutes, whether anyone can read your database.

Last updated

Firebase apps ship a config object to the browser, apiKey included. Like the Supabase anon key, that config is meant to be public and is not the problem. Your data is protected not by hiding the config but by your Security Rules, which decide who can read and write what. The common failure is shipping with rules still in test mode, which allows anyone to read everything. You cannot see that from the app, so you check.

Step 1: find your Firebase project details

Open your deployed app's developer tools and look in the page source or bundle for the firebaseConfig object. You want two fields: the projectId and, if you use the Realtime Database, the databaseURL (something like https://your-app.firebaseio.com). Both are already public.

Want to see exactly what Prbl flags? Watch it scan a demo app, no repo or account needed.

See a live scan →

Step 2: try to read, with no login

Firebase exposes a REST API, so you can make the same request an anonymous visitor could. For the Realtime Database, append .json to a path:

# Realtime Database — try to read a path with no auth
curl "https://your-app.firebaseio.com/users.json"

# open rules  -> returns the data as JSON
# locked rules -> {"error":"Permission denied"}

For Firestore, the REST endpoint lists documents in a collection:

# Firestore — try to list a collection with no auth
curl "https://firestore.googleapis.com/v1/projects/YOUR_PROJECT_ID/databases/(default)/documents/users"

# open rules  -> returns documents
# locked rules -> a 403 PERMISSION_DENIED error

Read the response. If you get back real data, your rules are open and anyone can read that collection or path. If you get a permission-denied error or nothing, your rules are doing their job. Try it against any path that holds user or private data.

Step 3: lock it down

For anything that returned data, replace the rules with ones that require authentication and scope access to the owner, and never ship test-mode or allow-all rules. Then re-run the check and confirm the anonymous request is now denied. The idea is the same one behind Row Level Security on other databases: the client key is public, so the rules are what protect you. More on the Firebase specifics in the Firebase Studio security overview.

Frequently asked questions

Is it a problem that my Firebase apiKey is in the browser?

No. The Firebase config, including the apiKey, is designed to be public and shipped to the client. It identifies your project; it does not grant access on its own. What actually controls access is your Security Rules. So finding firebaseConfig in your bundle is expected. The real question is whether your rules allow an anonymous request to read your data, which this guide checks.

What does test mode do to my rules?

Firebase test mode sets rules that allow any read and write for a period of time, so you can build without friction. The danger is that test mode expires quietly or gets extended, and apps ship with allow-all rules still in place. An app in test mode is fully open to anyone who has the config, which is everyone who loads the page. Always replace test-mode rules with real ones before launch.

What if my read returns no data or a permission error?

That is the good outcome. A permission-denied error, or an empty result, means your Security Rules are refusing the anonymous request, which is exactly what they should do for private data. You want a logged-out request to get nothing. If it returns actual documents or values, your rules are open and the data is public.

How do I fix open rules?

Write Security Rules that require authentication and scope access to the owner, for example allowing a read only if the requesting user's id matches the document's owner field. Never ship test-mode or allow-all rules. After updating, re-run the check and confirm an anonymous read is now denied. Do this for every collection or path that holds private data.

Or scan it automatically

The manual check covers the paths you think to try. Paste your app's URL into Prbl and it finds the exposed Firebase config and flags whether your rules leave data readable, so you are not guessing. Run a free scan and see whether your database is open. The same pattern shows up constantly in AI-built apps; we measured it here.

Prbl scans your live app or your codebase for exactly the kinds of issues above.

Is My Firebase Database Open? How to Check Your Security Rules: Prbl