whocanfixmyapp

Home / Problems / Data and database

Firebase rules are set to allow read, write: true

VC-42FirebaseUpdated October 2026By

Quick verdict

Partly fixable yourself. Editing rules is easy, writing correct ones is not

How serious
Critical
Fix it yourself?
Partly, some steps need a developer
Typical cost
$49–$800 one-off check, or €99–$990 for a single fix (prices)
Top rated
Afterbuild Labs · 10.0/10

What you see. Your Firestore, Realtime Database or Storage rules contain if true, or Firebase emailed you that your rules are insecure.

Why it happens

Firebase ships its project configuration to the browser by design, so Security Rules are the only lock on your data. When a database is created you choose Locked mode, which denies everyone, or Test mode, which grants everyone access. AI builders pick Test mode or write allow read, write: if true to get past a permission error, and never come back to it.

Firebase's own docs are blunt about this rule: never use it in production, because it allows anyone to overwrite your entire database. Without rules, anyone who guesses your project ID can steal, modify or delete the data. A softer version is just as common: a rule that only checks that a user is signed in. That lets any signed-up user, including someone who registered a minute ago, read every other user's records. Firebase suggests confirming you really want that before shipping it.

Fix it yourself

  1. In the Firebase console open your project, then Firestore Database, Realtime Database or Storage, and click the Rules tab. Search for if true and ".read": true.
  2. Replace open rules with owner rules. Firebase's example for data stored per user checks that request.auth is not null and that request.auth.uid equals the user id in the path.
  3. Find rules that only check for a signed-in user, written as auth is not null. Decide for each collection whether every logged-in user should see it. Usually the answer is no.
  4. Use the rules simulator in the console to test the new rules as a signed-out visitor and as a second user before you publish them.
  5. Publish the rules, then test the app with two accounts. Fix any permission errors in the app one by one rather than reopening the rule.
  6. Repeat for every product you use. Firestore, Realtime Database and Storage each have their own rules.

When to get an engineer

Hire an engineer when the app has many collections, admin screens, or shared data such as teams, or when the open rules were live while real users signed up. Tell them which products you use, how long the rules were open, and which screens must keep working. A one-off check of all rule sets costs $49–$800. Rewriting the rules and fixing the app code that relied on open access is a single fix at €99–$990, or more if the data model needs changes.

Top-rated companies

Ranked by our score: published prices, scope of work, AI tools named, timing and a low-risk first step. How we score.

  • 1Afterbuild Labs10.0/10Best for: A check before launchFree first step · from $49
  • 2Redlab10.0/10Best for: A full rescue by one team that keeps buildingFree first step · from $490
  • 3Vibe Code Rescue (Lev Arakelyan)9.0/10Best for: A one-off check and a cleanupFrom $299

All 79 companies, ranked

Check these

DATA-01Critical

Access rules are on for every table

In Supabase, open Table Editor: every table should show RLS enabled, with at least one policy. In Firebase, your rules should never say allow read, write: if true.

DATA-03Critical

One user cannot open another user's records

Sign in as user A, copy a request from the Network tab, and change the record ID to one that belongs to user B. You should get an error or an empty result.

DATA-04High

File storage is private where it should be

Upload a private file, copy its URL, and open it in a private window. If it loads, the bucket is public.

DATA-05High

Admin actions are checked on the server

Hiding an admin button is not protection. Call the admin endpoint as a normal user and confirm it is refused.

Questions

My Firebase apiKey is visible in the frontend. Is that the leak?

No. The client configuration is meant to be in the app. Firebase protects data with Security Rules, which is why open rules are the real problem.

Will tightening the rules break my app?

Probably, in places. Code that read other users' data or wrote without signing in will now get permission errors. Those errors show you exactly what to fix.

Sources: Firebase docs: Avoid insecure rules; Firebase docs: Basic Security Rules.