Advanced Security Rules
Firebase Firestore — Beyond FlutterFlow UI
A Practical Developer Guide using Posts & Chat Use Cases
1. Introduction
FlutterFlow and Firebase — A Quick Recap
FlutterFlow is a visual low-code platform for building Flutter applications. It connects natively to Google Firebase, using Cloud Firestore as the primary database layer. FlutterFlow generates production Flutter/Dart code behind the scenes and deploys it alongside Firebase backend services — meaning your data security is ultimately governed by Firebase, not your app's UI.
Every read, write, create, and delete request your app makes goes through Firebase before it reaches any data. This is where Security Rules live — and where advanced rules become essential for real-world applications.
What are Firestore Advanced Security Rules?
Firestore Security Rules are server-side access control policies written in a declarative language specific to Firebase. They evaluate every incoming request against conditions you define, and either allow or deny the operation before it reaches your database.
The 'advanced' aspect refers to rules that go beyond the four simple dropdowns FlutterFlow provides in its UI. Advanced rules allow you to:
- Validate field values: Ensure required fields exist, are non-empty, or fall within acceptable ranges before a document is written.
- Write custom helper functions: Reusable logic blocks (like isSignedIn() or isOwner()) that keep rules readable and maintainable.
- Cross-collection lookups: Check data in a different Firestore collection as part of the rule evaluation — e.g., verify a user has an active subscription.
- Multi-participant access: Allow access based on array membership — e.g., any participant listed in a chat's participants array can read its messages.
- Role-based access control: Grant different permissions to admins, moderators, and regular users based on a role field stored in their user document.
- Conditional field protection: Allow updates only to specific fields, preventing users from overwriting critical fields like created_by or created_at.
🔑 Core Principle
Advanced rules run entirely on Firebase servers. They cannot be bypassed by modifying the app, intercepting network calls, or using the Firebase SDK directly from a browser console. No matter how a request reaches Firebase — through your app, a script, or a REST call — the rules evaluate it the same way.
2. Why Advanced Rules — The Critical Gap
The Illusion of Security: UI Filtering vs. Server Rules
This is one of the most misunderstood aspects of app development, and understanding it correctly is the single most important reason to implement advanced rules.
⚠️ Real Scenario: The Filtered Query Problem
Imagine you have a posts collection. In FlutterFlow, you build a query to show 'My Posts' — you add a filter: created_by == currentUser. The screen displays only your posts. Everything looks correct.
But here is what is actually happening behind the scenes:
1. FlutterFlow sends a Firestore query with a where clause to the database.
2. Firebase loads ALL documents that pass the Security Rule check — not the UI filter.
3. If your Read rule is set to 'Authenticated Users' (or worse, 'Everyone'), Firebase returns ALL posts to the app.
4. FlutterFlow then applies the created_by filter CLIENT-SIDE, hiding the other posts from the visible list.
5. The other posts are FULLY LOADED in memory and visible in the browser's developer console or a network inspector.
A malicious user only needs to open DevTools → Network tab → inspect the Firestore WebChannel response to see every post loaded — regardless of the UI filter.
Visualising the Problem
Where FlutterFlow UI Rules Fall Short
FlutterFlow's built-in rule editor covers the most common scenarios well. But there are several situations where it simply cannot express what you need:
3. Types of Firestore Security Rules
Firestore Security Rules are built from a small set of composable primitives. Understanding each one is essential before writing any custom rules.
4. How Rules Work: Client-Side vs Server-Side
Understanding where data filtering happens is the most critical concept in app security. The distinction between client-side and server-side determines whether your data is truly protected or merely hidden.
Client-Side Filtering (What FlutterFlow Queries Do)
When you add a filter to a FlutterFlow query — such as 'show posts where created_by == currentUser' — you are adding a WHERE clause to the Firestore SDK request. This tells Firestore to return only matching documents. However, this filtering only works if the Security Rule also permits the read. If the rule says 'Authenticated Users can read all posts', then the full dataset is accessible regardless of what your app's query requests.
🔍 What Happens in the Browser DevTools
Open any Chrome browser. Go to DevTools → Network tab → filter by 'firestore'. Every document your app loads — even ones filtered from the UI — appears in full in the network response payload.
A non-technical user sees only their posts on screen. A developer or attacker opens DevTools and reads all 500 posts that were loaded but filtered client-side. This takes under 30 seconds and requires no hacking skill whatsoever.
This is not a theoretical threat. It is a standard technique used to extract data from apps with poor security rule configuration.
Server-Side Rules (What Firebase Enforces)
When a Firestore Security Rule evaluates a request, it runs on Google's servers before any data is returned. If the rule denies the operation, Firebase returns an error — not the data. The document bytes never travel over the network to the client at all.
This means even if a developer inspects network traffic, intercepts the SDK calls, or uses the Firebase REST API directly, they will receive a PERMISSION_DENIED error for any document their rule does not permit.
💰 Performance and Cost Benefit
Server-side rules do not just protect privacy — they protect your Firebase bill. Firestore charges per document read. If a query without proper rules loads 500 posts just to show 3, you pay for 500 reads. With a server-side rule that filters at the source, Firebase returns only the 3 relevant documents. At scale, this difference is significant.
5. Key Concepts Before Writing Rules
The request and resource Objects
Every rule condition has access to two built-in objects that describe the incoming operation and the existing state of the database.
How to access Advanced Rules
Go to the Firebase and search for the project, then from left side, access the Firestore. Here is the tab named as Rules where you can apply all of them.
Helper Functions — Keeping Rules Clean
Rather than repeating the same condition across multiple rules, you define it once as a function. This makes rules easier to read, test, and maintain.
// Define once at the top of your rules file
function isSignedIn() {
return request.auth != null;
}
function isVerified() {
return request.auth.token.email_verified == true;
}
function isOwner(ownerRef) {
return request.auth.uid ==
ownerRef.id;
}
function isParticipant(participants) {
return request.auth.uid in participants;
}
// Use them cleanly in rules
allow create: if isSignedIn() && isVerified();
allow update: if isOwner(resource.data.created_by);
allow read: if isParticipant(resource.data.participants);
Rule Evaluation: Allow-by-Default-Deny
Firestore Security Rules use a default-deny model. If no rule explicitly allows an operation, it is denied. Rules are not additive — if one rule allows and another denies, the allow wins only if the condition is satisfied. You do not need to write explicit deny rules; absence of an allow is itself a denial.
📌 Important: Rules are OR-evaluated
If you write multiple allow statements for the same operation, Firebase grants access if ANY of them evaluates to true. For example:
allow read: if isOwner(resource.data.created_by);
allow read: if isAdmin();
Both lines apply to read. A request passes if the user is either the owner OR an admin.
6. Practical Use Case: Posts, Chat, Reports & Blocks
We will now apply advanced rules to two real collections from a social app. The use case builds on the Posts collection from the introductory guide, and adds a Chat (one-to-one messages) collection, plus user Report and Block capabilities.
📌 Full App Scenario
Posts Collection:
• Only authenticated users with a verified email can create a post.
• Posts must have a non-empty title and body (field validation).
• All users (including guests) can read posts.
• Only the original author can edit their post — and cannot change created_by or created_at.
• Only the original author or an admin can delete a post.
Chat Messages Collection:
• Only participants listed in the chat document can read messages.
• Only participants can send (create) new messages.
• Messages cannot be edited once sent.
• Only the sender can delete their own message.
Reports Collection:
• Any authenticated user can report another user or post.
• Only admins can read all reports.
• Reports cannot be edited or deleted by anyone except admins.
Blocks Collection:
• Any authenticated user can block another user.
• A user can only read, create, or delete their own block records.
• Block records cannot be modified — only created or deleted.
Writing the Advanced Rules Step by Step
Step 1 Set Up the Rules File Structure
Every Firebase rules file starts with the same boilerplate. Open Firebase Console → Firestore Database → Rules tab.
Step 2 Write Shared Helper Functions
Define reusable functions at the top of the match block. These will be called across all collection rules.
💡 Why Helper Functions Matter
Without helper functions, the isAdmin() check would need to be copy-pasted into every rule that references it. If your users collection path ever changes, you would need to update it in a dozen places. Functions make rules maintainable.
Step 3 Posts Collection Rules
Now write the rules for the posts collection, calling the helper functions we defined above.
Breaking Down the Posts Rules
- Create — email verification: We check request.auth.token.email_verified to ensure the user has confirmed their email. This blocks users who registered but never verified.
- Create — field validation: title.size() > 0 and body.size() > 0 check that these fields exist and are not empty strings. This cannot be done in the FlutterFlow UI rules at all.
- Create — self-attribution: We verify the created_by field in the incoming document matches the current user's path. This prevents one user from creating a post attributed to someone else.
- Update — immutable fields: By checking that created_by and created_at in the incoming data match the existing data, we prevent the author from reassigning a post or changing its timestamp.
- Delete — admin override: Admins can delete any post regardless of authorship. This enables moderation. The isAdmin() function does a cross-collection lookup to verify the role field.
Step 4 Chat Messages Rules
The chat use case requires array-based participant checking — something impossible in the FlutterFlow UI. Each chat document has a participants array of user UIDs. Messages live in a subcollection.
Breaking Down the Chat Rules
- Participant check via get(): The isParticipant() function reads the parent chats/{chatId} document to check whether the current user's UID is in the participants array. This is a cross-document lookup — unavailable in FlutterFlow's UI.
- No message editing: update: if false means messages are immutable once sent, preserving chat integrity and preventing history tampering.
- Self-attribution enforcement: sent_by must equal the current user's UID at creation time, preventing one user from sending messages appearing to come from another.
- Subcollection inheritance: The match /messages/{messageId} block is nested inside match /chats/{chatId}, giving it access to the chatId variable for the participant lookup.
Step 5 Reports Collection Rules
Any signed-in user can file a report. Only admins can read the reports list. Nobody can edit a report — only create or (admin-only) delete.
🛡️ Why reported_by Must Match the Current User
Without this check, a malicious user could submit a report with reported_by set to someone else's UID — framing another user as the reporter. By enforcing reported_by == request.auth.uid at the rule level, the attribution is guaranteed regardless of what data the client sends.
Step 6 Blocks Collection Rules
A user can block another user. They can only see, create, and remove their own block records. No one can edit a block — only create or delete it.
Step 7 The Complete Rules File
Here is the full, production-ready rules file combining all collections from this guide.
7. Quick Reference Summary
8. Rule Keywords Glossary
Every keyword used in Firestore Security Rules has a specific scope and purpose. Some operate on a single document or single user — others are designed to work across lists, arrays, or multiple collections. The table below summarises every keyword used in this guide, what it targets, whether it handles a single value or a list, and where in the guide you can see it applied.
📖 How to Read This Table
Single — the keyword checks or matches one value at a time (e.g. one user UID, one field, one document).
List / Collection — the keyword operates on multiple values, an array of items, or a set of documents.
The 'Used In This Guide' column links to the section where the keyword is applied in a real rule.
Request & Resource Objects
These are the two built-in objects available inside every rule condition. They describe the incoming operation and the existing state of the database.
Match & Path Keywords
These keywords define which documents a rule block applies to. They are the structural skeleton of every rules file.
Allow Operations
These keywords declare which Firestore operations a rule block controls. Each one maps directly to a database action.
Cross-Collection Lookup Functions
These built-in functions allow a rule to read data from other parts of the database during evaluation. They are what make truly advanced access control possible.
List & Array Operators
These operators are specifically designed for rules that involve multiple users or values — such as checking whether a user is in a participants list. This is where advanced rules go beyond anything the FlutterFlow UI can express.
Logical & Comparison Operators
These operators combine and compare conditions inside rule expressions. They are the glue that connects multiple checks into a single allow statement.
Further Reading & Official References
The table above covers the keywords used throughout this guide. For the full Firebase Security Rules language reference, the resources below are the authoritative sources.
Advanced Security Rules Guide · FlutterFlow & Firebase · For the introductory guide, see: Security Rules Implementation using FlutterFlow
1. What are advanced Firebase Security Rules in FlutterFlow?
Advanced Firebase Security Rules are server-side access control policies that define who can read, create, update, or delete Firestore data. They allow developers to implement complex security logic beyond FlutterFlow’s default UI settings.
2. Why are Firebase Security Rules important for FlutterFlow apps?
Firebase Security Rules protect your Firestore database by validating every request before data reaches the application. They prevent unauthorized access, data leaks, and manipulation through APIs, scripts, or browser developer tools.
3. What is the difference between FlutterFlow UI rules and Firebase Security Rules?
FlutterFlow UI rules control what users see inside the application, while Firebase Security Rules protect data at the server level. UI filters can be bypassed, but Firebase Rules are enforced before data is delivered.
4. Can FlutterFlow filters protect Firestore data?
No. FlutterFlow filters only affect how data appears in the app. If Firebase Security Rules allow broader access, users may still receive unauthorized documents through network requests or developer tools.
5. How do Firebase Security Rules prevent data leaks?
Firebase Security Rules evaluate requests on Firebase servers before returning any data. If a user does not have permission, Firebase blocks the request and the protected data never reaches the client.
6. What are the main features of advanced Firestore Security Rules?
Advanced Firestore Security Rules allow developers to implement:
- Field validation
- Custom helper functions
- Role-based access control
- Cross-collection checks
- Ownership verification
- Multi-user permissions
- Immutable field protection
7. What is request.auth in Firebase Security Rules?
request.auth contains information about the authenticated user making a request. Developers use it to verify login status, access user UID information, and apply permission checks.
8. What is the difference between request.resource.data and resource.data?
request.resource.data represents the new document data being created or updated, while resource.data represents the existing document stored in Firestore before the operation.
9. How do I create role-based access control in FlutterFlow with Firebase?
Role-based access control can be created by storing user roles, such as admin or moderator, inside Firestore user documents and using Security Rules with functions like get() to verify permissions.
10. Can Firebase Security Rules check data from another collection?
Yes. Firebase Security Rules support cross-document lookups using get() and exists(). This allows rules to verify information such as user roles, subscriptions, or memberships stored in other collections.
11. How can I secure chat messages in FlutterFlow Firebase apps?
You can secure chat messages by storing participant IDs in the chat document and allowing access only when the authenticated user exists in the participants array.
12. Can Firebase Security Rules validate Firestore fields?
Yes. Security Rules can check whether required fields exist, prevent empty values, validate ownership fields, and restrict changes to important fields like created_by or created_at.
13. What are helper functions in Firebase Security Rules?
Helper functions are reusable logic blocks that simplify security rules. Functions like isSignedIn(), isOwner(), and isAdmin() help developers create cleaner and easier-to-maintain rules.
.svg)
.svg)
.avif)
