Do your Firebase rules make your data public?

Your Firebase data is public if your security rules let anyone read it. Open the Rules tab in the Firebase console, find any rule that allows reads without checking who is signed in, and lock each path so only its signed-in owner can read and write it.

What are Firebase security rules, and why do they matter?

Firebase Realtime Database security rules decide who can read and write your database. The rules live on Firebase's servers and are always enforced, and a read or write only goes through if the rules allow it.

By default, the rules grant no access to the database, which protects it until you customise the rules or set up sign-in. If your database is open, look for the rule that opened it.

Firebase apps run more of their code on the client side than many other stacks. Treat the rules as the lock on your data, and assume anyone can call your database directly.

Rules can let anyone read a path while still blocking writes to it. The .read and .write rules cascade, so read access on /foo/ also grants read access to everything below it, such as /foo/bar/baz. Rules at shallower, parent paths override the rules below them. Check the root and parent paths first.

How do I check?

Start with the rules themselves.

1. In the Firebase console, select your project, then go to Realtime Database, Cloud Firestore or Storage.
2. Click Rules once you're in the right database or storage.
3. Look for any .read or .write rule that lets everyone in, or that never mentions auth. Start at the root.
4. If you work from the Firebase CLI, the rules file is the one named in your firebase.json file.

The Firebase console always shows the most recently deployed version of your rules. Compare it with your local file before you change anything. Edit your rules with the same method you use to view them, console or CLI.

Here is how that looks on Atlas, our example app at atlas.example. Atlas keeps each user's notes under notes, one entry per user ID. If the root of Atlas's rules allowed reads for everyone, every user's notes would be readable, whatever the rules under notes said.

You can also look from the outside. Lockpick reads what anyone online can see about your site, within fixed limits, and reports only what it saw. If a scan flags your database, start with the open Firebase databases check page.

Check your site

How do I fix it?

1. Map who owns what. Write down, for each top-level path, who should read it and who should write it.
2. Add sign-in if you don't have it. Firebase Authentication lets users sign in to your app, with built-in support for Google, Facebook, email and password, anonymous sign-in and more.
3. Tie each rule to the user ID. Realtime Database rules can refer to authentication information, including the user ID from Firebase Authentication. These rules give each Atlas user read and write access to their own notes and nothing else:

{
  "rules": {
    "notes": {
      "$uid": {
        ".read": "auth != null && auth.uid == $uid",
        ".write": "auth != null && auth.uid == $uid"
      }
    }
  }
}

1. Remove open rules higher up. Delete any .read or .write rule at the root or on a parent path that lets everyone in.
2. Test before you deploy. Firebase's guide recommends running your app against one of the local Firebase emulators when you create rules. Sign in as one user and try to read another user's notes. That read should fail.
3. Deploy, then check again. Deploy with the same method you used to view the rules, then check again from outside.

If you use Cloud Firestore or Storage as well, each has its own Rules tab, so repeat these steps there.

If an AI coding assistant built your app, paste one of these fix prompts.

My app uses Firebase. Lock down its security rules so each signed-in user can only read and write their own data.
1. Find every Firebase rules file named in firebase.json (Realtime Database, Cloud Firestore and Storage).
2. List every rule that allows reads or writes without checking auth, starting at the root. Show me the list before changing anything.
3. Rewrite the rules so user data sits under a path keyed by the user ID, and allow read and write only when auth is not null and auth.uid matches that ID.
4. Remove any open read or write rule at the root or on a parent path.
5. Update the app code so it reads and writes under the signed-in user's own path.
6. Tell me how to test the new rules in the Firebase emulator with two accounts, and do not deploy until I confirm.

Review this project's Firebase security rules (the files named in firebase.json). Replace any rule that lets unauthenticated visitors read or write with owner-only rules. Each user's records live under a path keyed by their user ID, and access requires auth != null and auth.uid equal to that ID. Remove open rules on the root and parent paths. Update client code that reads other users' paths. Then write emulator tests that sign in as two different users and confirm neither can read the other's data. Show me the diff before applying it.

Audit the Firebase rules files referenced in firebase.json. Report each path that is readable or writable without sign-in. Then change the rules so only the signed-in owner can read and write their own records, matching auth.uid against the user ID in the path, and delete open rules higher in the tree. Adjust app code that depends on the old open access. Run the rules tests in the local Firebase emulator with two test accounts and show me the results. Do not deploy the rules.

What a check cannot tell you

Lockpick never signs in to your site, and never looks at anything behind a login. If your rules only check that someone is signed in, test for yourself whether one signed-in user can read another user's data, using two accounts in the emulator. Don't rely on an outside scan for that.

A report marks anything it couldn't check as not checked, never as passed. Don't read a clean result as proof your rules are right; read the rules.

A Lockpick report is not a certificate and not a full penetration test. It covers what that scan could see on that day.