How to Secure Your FlutterFlow Database with Firestore Rules

When you create a Firestore database in Firebase Console, the default test mode rules are: allow read, write: if request.time < timestamp.date(YEAR, MM, DD). These expire after 30 days and expose your database to any authenticated or unauthenticated request until then. In FlutterFlow, go to the Firestore panel (left sidebar) → click the Rules tab → you will see the current rules. Replace the entire rules block with a base rule that requires authentication for all operations. This single change blocks all unauthenticated API access to your database. Deploy the rules by clicking the Deploy Rules button in FlutterFlow's Firestore panel, or paste the rules into Firebase Console → Firestore Database → Rules and click Publish.

1// BEFORE: Test mode (INSECURE)
2rules_version = '2';
3service cloud.firestore {
4  match /databases/{database}/documents {
5    match /{document=**} {
6      allow read, write: if true;
7    }
8  }
9}

The baseline rule lets any authenticated user read or write any document. For collections containing user data (profiles, orders, messages), you need owner-only rules that check the requesting user's UID matches the document's owner field. In your users collection, the document ID should be the Firebase UID (FlutterFlow sets this automatically when you use Create Document with Current User UID as the document ID). Write a rule matching users/{userId} that allows read and write only when the request.auth.uid equals the userId path parameter. For other collections (like orders), the document has a userId field — compare request.auth.uid to resource.data.userId for reads and request.auth.uid to request.resource.data.userId for writes.

1rules_version = '2';
2service cloud.firestore {
3  match /databases/{database}/documents {
4
5    // Users: only the owner can read/write their profile
6    match /users/{userId} {
7      allow read, write: if request.auth != null
8        && request.auth.uid == userId;
9    }
10
11    // Orders: owner reads, owner creates (userId must match)
12    match /orders/{orderId} {
13      allow read: if request.auth != null
14        && request.auth.uid == resource.data.userId;
15      allow create: if request.auth != null
16        && request.auth.uid == request.resource.data.userId;
17      allow update, delete: if false; // orders are immutable
18    }
19
20    // Posts: any authenticated user can read,
21    // only owner can write
22    match /posts/{postId} {
23      allow read: if request.auth != null;
24      allow write: if request.auth != null
25        && request.auth.uid == resource.data.authorId;
26    }
27  }
28}

For admin dashboards or moderation tools, you need role-based access. The cleanest Firestore pattern stores the user's role in their users/{uid} document as a role field (String: 'user', 'admin', 'moderator'). The security rule fetches the requesting user's role document and checks the field. Use the get() function in rules: get(/databases/$(database)/documents/users/$(request.auth.uid)).data.role == 'admin'. This performs a server-side document read during rule evaluation. Note: each get() in rules counts as one Firestore read operation against your billing quota. For performance-sensitive apps with high traffic, consider using Firebase Custom Claims instead (set via Admin SDK in Cloud Functions) which embed the role in the JWT token and avoid the extra read.

1// Role-based access with Firestore user documents
2rules_version = '2';
3service cloud.firestore {
4  match /databases/{database}/documents {
5
6    // Helper function to get user role
7    function getUserRole() {
8      return get(/databases/$(database)/documents/
9        users/$(request.auth.uid)).data.get('role', 'user');
10    }
11
12    // Admin-only: full access to analytics collection
13    match /analytics/{doc} {
14      allow read, write: if request.auth != null
15        && getUserRole() == 'admin';
16    }
17
18    // Moderators and admins can delete flagged content
19    match /posts/{postId} {
20      allow read: if request.auth != null;
21      allow create: if request.auth != null;
22      allow update: if request.auth != null
23        && request.auth.uid == resource.data.authorId;
24      allow delete: if request.auth != null
25        && (getUserRole() == 'admin'
26          || getUserRole() == 'moderator');
27    }
28  }
29}

Security rules can validate incoming data to prevent users from writing invalid or malicious content. Check that required fields are present and have the correct type using the is operator and size() function. For example, prevent users from submitting a post with a title longer than 200 characters, or with a price field that is negative. Add validation conditions to your allow create and allow update rules using request.resource.data (the new data being written). Combine multiple conditions with &&. If any condition is false, the write is rejected server-side.

1// Field validation in security rules
2match /posts/{postId} {
3  allow create: if request.auth != null
4    // Must be the author
5    && request.auth.uid == request.resource.data.authorId
6    // Title must be a non-empty string under 200 chars
7    && request.resource.data.title is string
8    && request.resource.data.title.size() > 0
9    && request.resource.data.title.size() <= 200
10    // Body must be a string under 5000 chars
11    && request.resource.data.body is string
12    && request.resource.data.body.size() <= 5000
13    // Category must be one of the allowed values
14    && request.resource.data.category in
15       ['news', 'tips', 'question', 'announcement']
16    // No extra fields allowed (prevents injection)
17    && request.resource.data.keys().hasOnly(
18       ['authorId', 'title', 'body', 'category',
19        'createdAt', 'updatedAt']);
20}

Before deploying rules to production, test them in Firebase Console → Firestore Database → Rules → click the Rules Playground button at the top right. Select the operation (get, list, create, update, delete), enter a document path (e.g., users/abc123), and configure the authentication context (authenticated user with a specific UID, or unauthenticated). Click Run to see whether the operation is Allowed or Denied and which rule matched. Test every scenario: authenticated owner, authenticated non-owner, unauthenticated, admin user, invalid data. A common mistake is writing a rule that accidentally allows more access than intended — the playground catches this before it reaches users.