# Can anyone read your Firebase Realtime Database?

By Mark Kashef, founder of Lockpick. Published 2026-10-08, updated 2026-10-08.

This Deep scan check sends one shallow public read to the Firebase Realtime Database your site uses and flags it when entries come back.

This check sends one shallow public read to the Firebase Realtime Database your site uses, and flags it when entries come back. Only the number of top-level entries is kept.

## What does this check look at?

It looks at whether a Firebase Realtime Database your site uses answers a public read. Firebase says its security rules are the only safeguard blocking access for malicious users, and that by default your rules do not allow anyone access to your database.

Only a Deep scan runs it, after you prove you own the site. It applies only when the site code talks to a Firebase Realtime Database.

## What does a result mean?

| What the report shows | What it means | What to do |
| --- | --- | --- |
| Medium finding | A public read listed entries. | Require sign-in in the database rules, then read again. |

Only how many top-level entries answered is kept, so it cannot say what the data holds. Rules left open from test mode are the usual cause. A clean result means nothing was found in what the scan read. It does not prove the problem is absent from parts the scan never sees.

## How serious is a finding?

Fix this first when it is confirmed. Anyone could use a finding of this kind on their own, with no victim and no second step. Confidence starts high, because a response from your site shows the thing itself. The report lists what to fix by how directly someone could use it, not by the severity label.

### What does a confirmed finding have to show?

| Part | For this check |
| --- | --- |
| Where it starts | Anyone on the internet, with no account, cookie or credential |
| The protection that should stop it | Database rules allowed a public read |
| What is reached | A shallow read listed entries |
| What follows | Whatever those entries hold |

## Which standards does it relate to?

No OWASP, CWE or ASVS reference fits this check closely enough to state, so the report and this page leave it unmapped.

## Fix it with your AI

Change the rules in the Firebase console or your rules file, then test them before deploying.

:::fix-prompt any
My Firebase Realtime Database answers public reads. Rewrite my database rules so reads and writes require a signed-in user ("auth != null"), and scope each path to the user who owns it (for example data under users/$uid readable only when auth.uid === $uid). Keep public read only on paths that hold data meant for everyone, and list them for me. Show me the rules and how to test them in the rules simulator.
:::

## How to check

Say Atlas, our example app at `atlas.example`, started its database in test mode. A Deep scan sends one shallow read, counts the top-level entries and flags it.

Deep scans come with the Deep plan, and [pricing](/pricing) shows what it includes. [Pulse or Deep](/docs/get-started/pulse-or-deep) explains what each scan reads, and the [full list of checks](/checks) shows the rest.

## Questions people ask

### Did the scan read my data?

Only enough to count top-level entries. Their names and values are never kept, and nothing is written.

### Does this check Cloud Firestore too?

No. It covers the Realtime Database a site uses. Firestore rules need their own review.

## Sources

- [Basic Security Rules](https://firebase.google.com/docs/rules/basics), Firebase docs, read on 2026-10-07
- [How we rate findings](https://www.lockpick.app/docs/security/how-we-rate-findings), Lockpick docs, read on 2026-10-07
- [Understand Firebase Realtime Database Security Rules](https://firebase.google.com/docs/database/security), Firebase docs, read on 2026-10-07