How to Add Database Security to a Firebase Vibe-Coded App

Vibe-coded Firebase apps need extra database security because AI coding assistants routinely ship working apps on top of open or default-permissive rules. Roughly 45% of AI-generated code samples introduce OWASP Top 10-class vulnerabilities, and a review of 1,400 vibe-coded apps found 2,038 highly critical vulnerabilities plus over 400 leaked secrets, with open database rules among the most common failures.

What: Confirm whether your Firestore or Realtime Database rules are still in test mode or wide open before you touch anything else.

How: Open the Firebase console, go to Firestore Database or Realtime Database, then the Rules tab. If you see allow read, write: if true; in Firestore, or ".read": true, ".write": true in Realtime Database, the entire database is readable and writable by anyone who has your project's config values, which are not secret by design. AI coding assistants tend to generate this pattern because it makes the demo work on the first try, then never revisit it.

Red flags: An assistant that built working CRUD screens without ever asking about access control. A rules file you have never personally opened. A project still running on the 30-day test-mode rules that were supposed to expire and got redeployed instead. This gap is exactly why Joylo runs a real-time AI Confidence Score audit on every build, on every plan, flagging uncertain or risky code before it reaches production instead of after.

Checkpoint: You should now know, with certainty, whether your live rules currently allow open access. If they do, the next five steps are urgent, not optional. When a vibe-coded app comes in for an Expert Assist rescue review, this is the first tab Joylo's engineers open, before anything else in the codebase.

Locking down Firestore rules means starting from default-deny, granting access explicitly per collection, and validating data shape on every write, not just checking permission. Firebase's own guidance calls out the specific failure to avoid: test-mode rules that get pushed to production and are never tightened afterward.

What: Rewrite your Firestore rules to deny everything by default, then open access one collection at a time.

How: Start every ruleset with a catch-all deny, then add explicit allow statements scoped to a path, for example match /users/{userId} { allow read, write: if request.auth.uid == userId; }. Use helper functions for repeated checks so the rules stay readable instead of turning into a wall of conditionals. Validate the shape of incoming data on write, not just whether the request is allowed, since a permitted write with the wrong fields can still corrupt records. Test every rule change with the Rules simulator or the Firebase Emulator before deploying, per Firebase's official Firestore Security Rules documentation.

Red flags: A rule that grants access to any signed-in user (request.auth != null) without checking whose data it is. A rules file with no allow statements narrower than the collection root. Deploying straight from the console editor without ever running the simulator. On a self-serve Joylo plan, this is the point where a builder can add Expert Assist for a human to double-check the rules rather than shipping on a manual read-through alone.

Checkpoint: You should now have a Firestore ruleset where every collection has an explicit, scoped rule and nothing falls through to an implicit allow. This is the same first move Joylo's AI Confidence Score checks on every build, on every plan, before a human ever needs to look at it.

Securing a Realtime Database instead of Firestore means understanding its four rule types, .read, .write, .validate, and .indexOn, and its top-down inheritance model, where a broad rule at a parent path cascades to every child beneath it. A single .read: true at the root exposes the entire tree, not just one node.

What: Set Realtime Database rules to locked mode by default and build access up path by path, the same direction as Firestore but with different syntax.

How: RTDB rules are JSON, not a rules language, so a rule written at / applies to everything under it unless a deeper rule explicitly overrides it. Write .read and .write at the narrowest path that makes sense, for example /users/$uid, and use .validate to enforce data shape separately from access. Add .indexOn for any field you query on, since Firebase will otherwise flag slow, unindexed queries in the console. Firebase's Realtime Database Security documentation covers the full rule syntax and the locked-mode starting point.

Red flags: A broad rule set high in the tree "to make it easier," which then applies to every path underneath it, including ones added later by an AI assistant that has no visibility into the original intent. Rules that check .read but skip .validate, letting malformed writes through. In rescue reviews, this inheritance pattern is one of the first things Joylo's engineers check, since a rule that looks fine at the top of the tree can still leak access three levels down.

Checkpoint: You should now have RTDB rules where no parent path grants broader access than its narrowest child actually needs. Pull up the rules tree view in the console and confirm nothing inherits more than intended.

Scoping rules to the authenticated user, not just checking login, means tying every rule to request.auth.uid so access is limited to the specific user who owns the record. OWASP ranks broken access control as the number one web application risk, found in most tested applications, and an unscoped rule is a direct instance of it.

What: Replace any rule that only checks "is someone logged in" with a rule that checks "is this the specific user who owns this record."

How: In Firestore, compare request.auth.uid against a userId field stored on the document or embedded in its path, for example allow write: if request.auth.uid == resource.data.ownerId;. In Realtime Database, the equivalent is a rule keyed to $uid matching auth.uid. Apply this pattern to every collection or path that stores per-user data, not just the obvious ones like profiles. OWASP's Broken Access Control page is the reference for why this specific gap is treated as the most common, most exploitable class of vulnerability, not a minor oversight.

Red flags: A rule that reads if request.auth != null and stops there, letting any signed-in user read or write any other user's documents. Fields like userId that exist in the data but are never actually checked in the rule. Admin-only paths with no separate role check at all. This exact pattern is what Joylo's security audit is built to catch on every build, since it passes a surface-level test but fails the moment two users share the app.

Checkpoint: You should now be able to point to the exact line in every rule that ties access to a specific user, not just a login state. Joylo's engineers describe this as the rule that passes a skim but fails a real test: it mentions request.auth, reads as secure, and still lets one user touch another user's data.

Adding Firebase App Check on top of security rules closes a gap rules and Authentication cannot cover alone: it requires every API call to carry a valid attestation token proving the request comes from a genuine instance of your app, not a script. Google frames it plainly, Authentication protects the user, App Check protects the backend.

What: Enroll your app in Firebase App Check so backend resources reject calls that don't carry a valid attestation, even if the caller somehow has valid credentials.

How: In the Firebase console, go to App Check, register your app, and choose a provider, reCAPTCHA for web, Play Integrity for Android, or App Attest for iOS. Enable enforcement for Firestore, Realtime Database, and any other Firebase product your app calls. Run in "monitor mode" first so you can see which legitimate requests would be blocked before you flip to full enforcement. Firebase's App Check documentation covers setup per platform and per product.

Red flags: Enabling enforcement immediately without a monitoring period, which can lock out legitimate traffic you didn't account for. Skipping App Check because "the rules are already locked," which ignores that App Check protects against abuse of correctly permissioned endpoints, not just broken ones. This is the kind of layered gap a Joylo Co-Build architect checks for as part of a certified architect review, not a one-time scan.

Checkpoint: You should now see App Check tokens attached to requests in the Firebase console's usage metrics, with enforcement active on every product that supports it. This is the same layered logic behind Joylo's five-domain AI Confidence Score audit, which checks security alongside scalability, reliability, integrations, and code quality on every build, on every plan.

You verify your rules are locked by running Firebase's own tooling against the live ruleset, not by re-reading it manually: open the Rules tab, work through the official security checklist, and re-run the Rules simulator immediately before launch. New Firestore and Realtime Database instances deny access by default, so production failures trace to misconfiguration, not weak defaults.

What: Run a final check against your live rules using Firebase's own tooling, not just a manual read-through.

How: Open the Rules tab in the Firebase console. Firebase itself flags high-risk patterns, rules granting full read and write access to any authenticated or unauthenticated user, directly in the interface, per Firebase's "Avoid insecure rules" guidance. Work through the official Firebase security checklist, which covers App Check enrollment, API key restriction, and alerting for abnormal read and write volume, not just the rules themselves. Re-run the Rules simulator against your production ruleset one more time immediately before launch.

Red flags: A console warning you have seen before and dismissed without acting on it. No monitoring or alerting configured for unusual traffic spikes, which is often the first sign a ruleset has a gap someone found. If this checklist turns up more than a couple of open items, that is usually a sign to bring in a second set of eyes rather than working through the backlog alone.

Checkpoint: You should now have zero unresolved warnings in the Firebase console's rules view, App Check enforcement active, and at least basic alerting configured. Joylo is built by HST Solutions, an 18-year Dublin engineering firm, and its in-house engineers run this exact checklist as the first pass in every Expert Assist security review.

What Are the Most Common Firebase Database Security Mistakes?

The most common Firebase database security mistakes are test-mode rules left in production, rules that check login but not ownership, and treating App Check as optional once rules look correct. Each one lets an otherwise well-built app leak or lose data the moment real users start using it.

• Shipping test-mode rules. Firebase's test mode grants open, time-limited access to speed up early development, and it is meant to expire. The mistake is redeploying it, or letting it silently renew, once the app is live. Fix: replace it with default-deny rules before any real user signs up, per Firebase's guidance on insecure rules.

• Checking login instead of ownership. A rule like if request.auth != null passes for every signed-in user, not just the one who owns the record. Fix: add a request.auth.uid comparison to the specific resource on every rule that touches per-user data.

• Treating App Check as optional. Teams that lock down rules sometimes skip App Check, assuming rules alone are enough. They are not; App Check stops abuse of endpoints that are otherwise correctly permissioned. Fix: enroll in App Check as part of the same pass where you lock down rules, not as a separate future task.

• No monitoring after launch. Rules that were correct at launch can become wrong as new collections get added by an AI assistant that has no memory of the original access model. Fix: set up basic alerting for abnormal read and write volume, per the Firebase security checklist.

• Assuming a working demo means a secure app. A demo only proves the happy path works, not that access is scoped correctly. This is the exact gap Joylo's AI Confidence Score is built to catch automatically, flagging uncertain or risky code before it reaches production, on every build, on every plan.

When Does This Security Framework Change?

This framework changes once your app moves past a single-tenant, per-user data model, starts handling regulated data, or scales past the point where manual rule review keeps pace with new collections. At that point, default-deny plus App Check is necessary but no longer sufficient on its own.

• Multi-tenant or team data. Once records are shared across a team or organization instead of owned by one user, rules need role-based logic, not just uid matching, which is significantly harder to get right by hand.

• Regulated data. Apps handling health, financial, or other regulated data need a full engineer-led architecture and access review, not just locked rules. Joylo's Co-Build plans include this level of continuous review, and Enterprise plans add dedicated security and compliance support for exactly this stage.

• Rapid schema growth. An AI assistant adding new collections weekly can outpace a rules file that was written for the app's original three tables. At that point, a scheduled rules audit, not a one-time lockdown, becomes the right cadence.

• Team growth. Once more than one person can push rule changes, a review step before deploy matters as much as the rules themselves, since a single unreviewed change can reopen a path that was previously locked.

What Do Real-World Firebase Security Lockdowns Look Like?

Real-world Firebase security lockdowns look different depending on how far the app has already shipped: a pre-launch app can work through all six steps in a single session since no live traffic is at risk, while a live app with paying users has to close the same gaps in production without breaking features people already depend on.

Scenario 1: Pre-launch solo builder. A non-technical founder vibe-coded a booking app on Firestore over three weekends and is two weeks from a public launch. The rules are still in test mode. Working through Steps 1 through 6 in order, starting from default-deny and scoping every rule to request.auth.uid, is realistic to finish in a single focused session before launch, since there is no live traffic to avoid breaking.

Scenario 2: Live app with paying users. A small team's Realtime Database app has been live for four months on rules that check auth != null but not ownership. Locking down rules here carries real risk of breaking a feature that was quietly depending on open access, so the safer path is testing every rule change in the Rules simulator against production data patterns before deploying, then rolling out App Check in monitor mode before full enforcement. A team in this position is a natural fit for Joylo's Expert Assist, where a named in-house engineer reviews the existing rules and data model before anything changes in production.

If your Firebase rules are still open before launch, check out Joylo's Expert Assist. Get Expert Assist