Firebase security rules decide who can read and write the data in your Firestore database, Realtime Database and Cloud Storage. If your app was built with AI tools and runs on Firebase, a check of those rules belongs on the list before launch or before the first paying customers sign up.
This guide is for anyone running an AI-built app on Firebase who has never had to read security rules. It explains what the rules do, names five gaps an AI-built project can ship with, gives three checks you can run or ask your developer to show, and covers what GDPR leaves to you. The guide is part of our series on shipping AI-built products safely.
TL;DR
Firebase security rules are server-side rules that decide what each read and write to Firestore, Realtime Database and Cloud Storage may do. The app talks to the database straight from the phone or browser, so the security rules are the only gate. Access is granted when any matching rule allows it, so one loose rule can open data that stricter rules protect.
- Five gaps: test-mode or allow-all rules, Admin SDK code that skips the rules, sign-in checks without ownership checks, permissive Cloud Storage rules, and unvalidated writes without App Check.
- Three checks you can run: read the Rules tab, test what a logged-out visitor and a second account can read, and confirm every personal-data path checks the owner.
- The threshold: any red flag on a collection or bucket with personal data is a fix before more users sign up.
What are Firebase security rules?
Firebase security rules are access rules that Google’s servers enforce on every read and write to Cloud Firestore, Realtime Database and Cloud Storage. The app on a phone or in a browser cannot skip them, because the check happens on the server and not in the app’s code.
In a traditional set-up, the app talks to your own server, and the server decides what each user may see. A Firebase app talks to the database directly. There is no backend in front of your Firebase database: the security rules are the backend for access.
Each rule names a path, such as a collection of invoices, and a condition. The condition can look at who is asking through request.auth, the identity of the signed-in user.
Two behaviours shape the rest of this guide. First, one allow wins: in Firestore and Cloud Storage, when several rules match the same path, access is granted if any of them allows it. A strict rule for invoices does not help when a broader rule allows everything. Second, server code that uses the Admin SDK, such as a Cloud Function, skips security rules entirely.
5 Firebase security gaps in AI-built apps
The five Firebase security gaps below each let a stranger or another user reach data that the app’s screens never show. Each gap is a launch blocker when the affected path holds personal data.
| Gap | What it looks like in plain words | What a stranger or another user can do | Launch blocker? |
|---|---|---|---|
| Test-mode and allow-all rules | The rules contain the word “true” or a date | Anyone on the internet can read, change or delete the data without signing in | Yes |
| Admin SDK access | A Cloud Function fetches data without checking who asked | Any caller of that function receives data the rules would have refused | Yes, when personal data is stored |
| Authentication without authorization | The rules check “signed in” and nothing else | Any account, including a new one, can read every user’s records | Yes, when personal data is stored |
| Permissive Cloud Storage rules | Uploaded files have no per-user rule, or no limit on size and type | Another user can open your customers’ files or upload files of any kind | Yes, when personal data is stored |
| Unvalidated writes and missing App Check | Users can edit every field on their own record, including role or plan | A user can make themselves an admin or upgrade without paying | Yes, when personal data is stored |
Test-mode and allow-all rules left in production
An allow-all rule lets anyone on the internet who has your app’s public configuration read, change or delete the data the rule covers, without signing in. Test-mode rules do the same until a set date. That configuration ships inside every copy of the app, so it is no password.
A Firebase database can be started in test mode, with rules that allow every read and write until an expiry date. When the date passes, the app stops working; when someone extends the date, the data stays open. A second route is the “permission denied” error: when an AI coding tool meets it, the shortest change that makes the error disappear is a broader rule.
In the rules, look for a condition that is simply true (allow read, write: if true;), which Firebase’s own documentation says to never use in production. Look also for a date, for .read or .write set to true at the top level of a Realtime Database, and for a match on the whole database, which overrides every stricter rule because one allow wins. If your rules file has not changed since the first week of the project, assume it still reflects test mode.
Admin SDK access: rules bypassed, credentials exposed
Code that uses the Firebase Admin SDK, including Cloud Functions and your own servers, bypasses security rules entirely. A Cloud Function that returns a record without checking who asked will hand that record to any caller, however strict the rules are. Each function therefore needs its own ownership check.
This gap can grow out of a reasonable fix. When security rules block a feature, one way to make the feature work is to move the logic into a Cloud Function that reads with admin rights. The rules still look tight in the console, while the function has become a side door.
The Admin SDK signs in with a service account key, which Firebase tells developers to store securely. A service account key shipped inside the app or committed to a public repository gives its holder the same admin access. See our guide on secrets exposed in frontend code.
Authentication without authorization (missing ownership checks)
A rule that only checks whether someone is signed in lets every account read every user’s records, including an account a stranger created a minute ago. Authentication establishes who a user is; authorization decides what that user may touch. Rules that stop at authentication keep out visitors, not other users.
The pattern is request.auth != null with nothing after it. Firebase’s documentation shows that rule as a starting point and states that it is not recommended for production applications. The rule can survive until launch because the builder signs in with one account that owns all the test data, so a missing owner check never shows on screen.
A safe rule compares the signed-in user’s ID (request.auth.uid) with the owner recorded on the document. A missing ownership check is the most direct form of broken access control.
Permissive Cloud Storage and file upload rules
Files that users upload, such as ID documents, invoices and photos, are protected by Cloud Storage rules, which are written separately from the database rules. If the Storage rules let any signed-in user read every file, tight Firestore rules do not protect those files, and one customer can open another customer’s documents.
Storage rules can be left behind because work on rules follows the errors, and the database is where the first errors appear. Cloud Storage rules can limit the size and type of an uploaded file; without those limits, a user can put files of any size or kind into your bucket. The signals are a Storage rule that only checks sign-in and a file path with no per-user folder.
Unvalidated writes and missing App Check
A rule that lets users update their own profile record without limiting which fields they may change lets them change every field in it. If that record also stores a role, a plan or a credit balance, a user can make themselves an admin or move to a paid plan without paying.
Security rules can inspect the incoming data and reject changes to fields a user should not control. For roles, the safer design keeps them out of user-writable records altogether. Custom claims are labels on a user’s sign-in token, set only from server code through the Admin SDK and readable in security rules.
App Check is a Firebase service that verifies requests come from your genuine app and not from a script. App Check does not replace security rules: a genuine app in the hands of a curious user still sends requests, and the security rules decide what those requests may read or write.
How to check your Firebase rules
Three checks show whether your Firebase rules are open. You can run the first and ask your developer to show the other two.
Inspect your Rules tab
The Rules tab in the Firebase console shows the security rules that are live right now, and scanning it for red flags takes no coding knowledge. Open the tab for each product the app uses: Firestore, Realtime Database and Storage. Look for the four red flags from Table 1: the word “true” as a condition, a date, a sign-in check with nothing after it, and a match on the whole database.
Firebase can also alert a project that its data is not properly secured. Treat such an alert as a finding and forward it to your developer.
See what a logged-out visitor and a second account can see
The second check tests the security rules instead of reading them. Can a logged-out visitor read anything, and can account B read account A’s data? For every path with personal data, both answers should be no.
The Rules Playground in the Firebase console simulates a single read or write as a signed-out or signed-in user, for Firestore, Realtime Database and Storage. For repeatable proof, ask your developer to run logged-out and second-account tests in the Firebase Local Emulator Suite before each deploy, and to show you the test file.
A test file without a second-account test is itself a finding. The full method is in our guide to testing AI applications.
Confirm every personal-data path checks the owner
The third check is a conversation with your developer about coverage: every place that holds personal data should have a rule that names the owner. Ask three questions and ask for the answers in writing.
- “Which collections and Storage paths hold personal data, and which rule protects each one?”
- “Which fields can a user write on their own record?”
- “Which Cloud Functions use the Admin SDK, and what does each one check before it reads or writes data?”
Nothing in the Rules tab reveals a function that skips the rules, so the third question deserves the most attention. Use one threshold for all three checks: any red flag on a collection or bucket with personal data is a fix before more users sign up.
If you found a date, a “true” or a rule that only checks whether someone is signed in, your data may be more open than the app’s screens suggest. In an independent review, Sunbytes reads your security rules together with the Cloud Functions that bypass them and tells you in plain English what to close first.
Is Firebase secure enough for a production app?
Firebase is secure enough for a production app when its security rules are owner-based, tested and reviewed, and it is a liability when the rules were never changed after test mode. The platform is not the variable. Google secures the infrastructure; you own the rules, the data model and any code that uses the Admin SDK. That split is called shared responsibility.
For a European company, two decisions sit on your side of that split.
Data location. A Firestore database is created in a location you choose, and the location cannot be changed afterwards. Firebase offers a European multi-region and single European regions such as Frankfurt. Moving a US database to Europe means creating a new database and migrating the data.
GDPR roles and security. Under Google’s Firebase Data Processing and Security Terms, Google is a processor of customer personal data where European data protection law applies. Where your company decides why and how that data is used, your company is the controller. GDPR Article 28 requires a contract between controller and processor, and Article 32 requires security measures appropriate to the risk. Security rules that leave personal data readable by any account are difficult to defend under Article 32. This paragraph is general information, not legal advice.
Confirm the data location and the state of your security rules before a B2B customer’s security questionnaire asks about them.
Firebase rules and Supabase RLS: same problem, different layer
Firebase security rules and Supabase Row Level Security (RLS) solve the same problem at different layers: both decide which user may reach which data when the app talks to the database directly. Neither platform is safer by default. The safer choice is the one your team can write and test access rules for.
| Criterion | Firebase security rules | Supabase RLS |
|---|---|---|
| Where the rules live | In a rules file per product (Firestore, Realtime Database, Storage), enforced by Firebase | In policies on each database table, enforced by the Postgres database |
| Language | Firebase’s own rules language (JSON for Realtime Database) | SQL |
| Gap to look for in an AI-built project | Test-mode rules or a sign-in check without an owner check | RLS switched off on a table, or a policy that allows every row |
| Path that skips the rules | Server code using the Admin SDK | Server code using the service_role key |
| How to test | Rules Playground and Local Emulator Suite tests | Requests made as a logged-out user and as a second user |
If you are migrating from one platform to the other, review the rules on both sides before switching traffic. Owner checks do not carry over from Firebase security rules to Supabase policies, or back. The Supabase side is covered in our guide to Supabase RLS.
Closing the gaps without breaking the app
Closing Firebase rule gaps safely means tightening in a fixed order and testing each step, because a rule that is too strict breaks features for real users. Seven steps cover the five gaps:
- Start from deny-all.
- Add owner-based rules per collection. Each rule compares the signed-in user with the owner on the record.
- Validate writable fields and reject changes to the rest.
- Move roles to custom claims set by server code.
- Lock Storage paths per user and limit file size and type.
- Test in the Emulator as a logged-out visitor, as the owner and as a second account.
- Deploy rules separately from app code. Security rules are defined outside the app, so a rules change can be released, and reversed, without a new app version.
App Check is an extra layer on top of these steps and not a substitute for any of them. The Firebase web API key identifies the project and is not a secret. Service account keys and third-party API keys are secrets and must never ship in the app.
Done means three things are true: no rule contains “true” or a date, every personal-data path checks the owner, and the Emulator tests run on every deploy.
How Sunbytes reviews Firebase-backed products
Tight rules cover half of a Firebase app: every Cloud Function that uses the Admin SDK skips them, so the code behind the rules needs the same scrutiny. Our Sunbytes AI-built product review therefore reads the security rules, the data model and the server code in one pass, with software engineering and security looked at together.
You get the findings, the evidence behind each one and a plan for what to fix first, written in plain English. A technical handoff tells your developer or AI coding tool what to do. The work is led from the Netherlands, with engineering delivery in Vietnam, under an ISO 27001-certified information security management system, and it draws on 15+ years and 300+ delivered projects.
Scope depends on your product, so talk to us for case-by-case advice. If a store launch is next, our AI-built mobile app review guide lists the checks to run before submission.
