How I Would Fix database rules leaking customer data in a Flutter and Firebase automation-heavy service business Using Launch Ready.

How I Would Fix database rules leaking customer data in a Flutter and Firebase automation-heavy service business Using Launch Ready

The symptom is usually ugly and expensive: one customer can see another customer's records, admin-only data shows up in a client app, or support starts getting screenshots of private automations, emails, and order details that should never have been visible. In a Flutter and Firebase service business, the most likely root cause is bad Firestore or Realtime Database rules combined with queries that assume the client app will "behave" instead of enforcing access at the database layer.

The first thing I would inspect is the actual rule file in production, then I would compare it to the app's read paths and any Cloud Functions or backend jobs that write shared data. If the business runs on automation-heavy flows, I would also check whether a service account, admin SDK, or callable function is bypassing the same access controls that the mobile app relies on.

Triage in the First Hour

1. Open the live Firebase console and confirm which database is leaking:

• Firestore
• Realtime Database
• Storage metadata
• Callable functions returning private data

2. Review the deployed security rules, not just the local file:

• Firestore rules
• Realtime Database rules
• Storage rules
• Any recent rule changes in Git history

3. Check recent access patterns in logs and analytics:

• Unusual reads from anonymous users
• Reads from one tenant ID to another tenant's documents
• Sudden spikes after a deploy

4. Inspect Flutter screens that render customer data:

• List views
• Detail pages
• Admin panels hidden behind feature flags
• Cached offline data paths

5. Verify all backend entry points:

• Cloud Functions
• Scheduled jobs
• Webhooks from Stripe, Zapier, Make, GoHighLevel, or similar tools
• Admin SDK usage

6. Compare production env vars and secrets:

• Firebase project ID
• API keys
• Service account JSON handling
• Branch-specific config files

7. Roll back only if leakage is active and you cannot isolate it fast:

• Freeze writes if needed
• Disable risky endpoints first
• Preserve logs for incident review

8. Notify support and ops with one clear message:

• What leaked
• Who may be affected
• Whether access has been cut off
• When next update will land

A fast diagnostic command I would run during triage:

firebase deploy --only firestore:rules,database,rules,storage --project production-project-id

That command does not fix anything by itself, but it confirms what is actually deployed and forces me to compare local intent against live state.

Root Causes

| Likely cause | What it looks like | How I confirm it | |---|---|---| | Overly broad allow rules | `allow read: if true;` or weak auth checks | Inspect live rules and test as anonymous and authenticated users | | Missing tenant isolation | Users can query documents by ID across accounts | Review document structure for `tenantId`, `orgId`, or `ownerId` enforcement | | Client-side filtering only | App hides data in UI but database still returns it | Check whether queries return too much before filtering in Flutter | | Callable function bypass | Cloud Function returns unrestricted records using Admin SDK | Audit function code and logs for missing authorization checks | | Bad query shape with permissive rules | Rules allow collection reads without matching ownership constraints | Compare Firestore query filters to rule conditions | | Shared automation accounts | Zapier/Make/webhook jobs write into broad collections | Review service account permissions and write targets |

The biggest mistake I see founders make is assuming "the app screen looks fine" means the system is safe. If Firestore rules are wrong, the business has a security problem even if the UI only exposes part of it.

The Fix Plan

I would fix this in a controlled order so we do not break production while trying to secure it.

1. Freeze public exposure first.

• If leakage is active, temporarily block risky reads.
• Disable non-essential automations that touch shared collections.
• Keep core billing or booking flows alive where possible.

2. Map every data type to an owner.

• Customer profile data.
• Orders.
• Automations.
• Internal notes.
• Admin-only operational records.

3. Move to explicit ownership checks.

• Every record should have a clear `ownerId`, `tenantId`, or `orgId`.
• Rules should verify authenticated user identity against that field.
• Avoid relying on obscurity like random document IDs.

4. Tighten Firestore or Realtime Database rules.

• Deny by default.
• Allow only specific reads and writes.
• Separate admin paths from customer paths.

5. Audit server-side code that uses Admin SDK.

• Admin SDK bypasses client security rules by design.
• That means every function must enforce authorization manually.
• Add checks before returning any sensitive payload.

6. Fix Flutter queries to match rule expectations.

• Query by tenant scope first.
• Do not fetch broad collections then filter locally.
• Remove any screens that expose raw debug collections.

7. Rotate secrets if exposure included credentials or tokens.

• Regenerate service account keys if they were mishandled.
• Rotate third-party API keys used by automations.
• Review who has access to Firebase project settings.

8. Add a safe fallback path for customers.

• Show "data temporarily unavailable" rather than partial unsafe data.
• Keep onboarding and support workflows intact with manual handling if needed.

9. Deploy in stages.

• First deploy rules only.
• Then deploy backend fixes.
• Then ship Flutter client updates if needed.

10. Document exactly what changed.

• Which collections are now protected?
• Which roles can read what?
• Which automations were paused?
• What needs follow-up after launch?

For an automation-heavy service business, I would usually recommend one path: lock down server-side ownership first, then repair UI assumptions second. If you do it backwards, you can hide leaks without actually fixing them.

Regression Tests Before Redeploy

I would not redeploy until these checks pass:

1. Authenticated user A cannot read user B's records. 2. Anonymous requests fail on all protected paths. 3. Admin users can still access required operational data through approved routes only. 4. Cloud Functions reject requests without valid identity and role checks. 5. Flutter lists return only scoped records for the signed-in account or org. 6. Offline cache does not surface stale sensitive records after logout. 7. Webhooks write only to intended tenant records. 8. No debug screen exposes raw documents in production builds.

Acceptance criteria I would use:

• 100 percent of protected collections deny unauthenticated reads unless explicitly public.
• Tenant-scoped reads return zero cross-account results in test cases for at least 3 sample tenants.
• Security rule tests cover at least 90 percent of critical rule branches.
• No P1 privacy leak remains open before release.
• p95 auth-related request latency stays under 300 ms after rule changes.

A practical QA pass should include:

• Manual testing on iOS and Android builds.
• Signed-in user switching between two test accounts on the same device.
• Logout/login cache verification.
• Negative tests for deleted users and revoked roles.
• Rule tests in CI before merge.

Prevention

I would put guardrails in place so this does not come back after the next quick build or automation tweak.

1. Security-focused code review:

• Every new collection gets an owner model before merge.
• Every function gets explicit authorization review.
• No "temporary" open rules survive into prod.

2. Rule tests in CI:

• Add automated Firebase emulator tests for allow/deny cases.

```js test("user cannot read another tenant", async () => { // assert deny for mismatched tenantId });

3. Least privilege on accounts:
   - Separate human admin access from service accounts.
   - Restrict who can edit Firebase settings, secrets, and billing integrations.

4. Monitoring and alerting:
   	- Alert on spikes in reads per user or per collection.
   	- Alert when admin endpoints are hit by unexpected identities.
   	- Track failed auth attempts and unusual function invocations.

5. Safer UX patterns:
   	- Hide internal identifiers from end users where possible.
   	- Make permission errors clear without exposing system details.
   	- Show empty states instead of partial cross-account data.

6. Performance discipline:
   	- Keep queries narrow so you do not rely on client-side filtering under load.
   	- Watch p95 response times after adding stricter checks because slow auth logic can hurt conversion during onboarding.

7. Release process discipline:
   	- Require one security reviewer for rule changes.
   	- Block direct-to-prod edits in Firebase console except emergencies logged afterward.

## When to Use Launch Ready

Launch Ready fits when you need this fixed fast without turning your product into a longer consulting project.

What Launch Ready includes matters here because leaked data problems often sit next to broken deployment basics:
- DNS cleanup and redirects
- Subdomains set up correctly
- Cloudflare protection and caching
- SSL live everywhere
- SPF, DKIM, DMARC configured
- Production deployment verified
- Environment variables audited
- Secrets checked and rotated where needed
- Uptime monitoring added
- Handover checklist delivered

What you should prepare before booking:
1. Firebase project access with admin rights limited to someone accountable internally or via temporary invite only,
2. current Flutter repo,
3. list of all customer-facing collections,
4. list of automations connected to the app,
5. any recent incident screenshots or support tickets,
6. current deployment pipeline access,
7. top 3 user journeys that must stay online during remediation.

If your business depends on leads converting inside 48 hours, I would prioritize security fixes that preserve booking flow over cosmetic refactors every time.

## Delivery Map

flowchart TD A[Founder problem] --> B[cyber security audit] B --> C[Launch Ready sprint] C --> D[Production fixes] D --> E[Handover checklist] E --> F[Launch or scale]

## References

1. https://roadmap.sh/cyber-security
2. https://roadmap.sh/api-security-best-practices
3. https://firebase.google.com/docs/firestore/security/get-started
4. https://firebase.google.com/docs/rules
5. https://firebase.google.com/docs/functions/auth-events

---

## Take the next step

If this is a problem in your product right now, here is what to do next:

- **[Use the free Cyprian tools](/tools)** - estimate cost, score app risk, check launch readiness, or pick the right service sprint.

- **[Book a discovery call](/contact)** - I will tell you honestly whether you need a sprint or if you can DIY the next step.

*Written by Cyprian Tinashe Aarons - senior full-stack and AI engineer helping founders rescue, launch, automate, and scale AI-built products.*