How to Improve Your FlutterFlow App's Security

This is the most critical security fix. In the Firebase console, click Firestore Database in the left sidebar, then click the Rules tab. If you see 'allow read, write: if true;' — your database is completely public. Anyone with your project ID can read, write, and delete all your data. Replace the rules immediately with the template below that restricts all operations to authenticated users accessing only their own data. For collections that need different permissions (like public content or admin-only data), add specific rules above the default deny-all at the bottom.

1rules_version = '2';
2service cloud.firestore {
3  match /databases/{database}/documents {
4
5    // Users can only read and write their own profile
6    match /users/{userId} {
7      allow read, write: if request.auth != null
8        && request.auth.uid == userId;
9    }
10
11    // Users can read public articles; only authors can write
12    match /articles/{articleId} {
13      allow read: if true;
14      allow create: if request.auth != null;
15      allow update, delete: if request.auth != null
16        && request.auth.uid == resource.data.author_id;
17    }
18
19    // Orders: users see only their own; admins see all
20    match /orders/{orderId} {
21      allow read, write: if request.auth != null
22        && request.auth.uid == resource.data.user_id;
23      allow read, write: if request.auth != null
24        && request.auth.token.admin == true;
25    }
26
27    // Default deny-all for everything else
28    match /{document=**} {
29      allow read, write: if false;
30    }
31  }
32}

FlutterFlow compiles your app into JavaScript (for web) and Dart (for mobile). Any API keys you store in App State variables, Custom Actions, or widget properties are visible in the compiled app bundle — any user can extract them with basic tools. Instead, create a Firebase Cloud Function for each third-party API call (Stripe, SendGrid, OpenAI, etc.). Store API keys as Firebase environment secrets using 'firebase functions:secrets:set MY_API_KEY'. The Cloud Function reads the secret at runtime, makes the API call, and returns only the needed data to the app. In FlutterFlow, call the function using a Custom Action that hits the Cloud Function's HTTPS endpoint.

Firebase App Check verifies that requests to your Firebase services come from your legitimate app and not from curl, Postman, or a competitor's script. In the Firebase console, go to App Check under the Build section. Click 'Get started', select your app (iOS and Android separately), and choose the attestation provider: Play Integrity for Android and App Attest for iOS (both free). On the Web, use reCAPTCHA Enterprise. Once enabled and enforced, only verified app instances can call Firestore, Storage, and Cloud Functions. Enforcement takes effect 7 days after enabling — use the debug token feature during development to test without affecting your real usage metrics.

FlutterFlow's form validation (required fields, email format) only runs on the client. A determined attacker can bypass the app entirely and send malformed data directly to Firestore. Add server-side validation in two places: first, in your Firestore security rules using request.resource.data conditions to enforce field types and lengths; second, in Cloud Functions that handle sensitive writes. Check string lengths (request.resource.data.username.size() < 50), reject special characters in fields that should not have them, and verify numeric fields are within acceptable ranges. Never trust that data stored in Firestore was written by your app.

1// Firestore rule example: validate article fields on create
2match /articles/{articleId} {
3  allow create: if request.auth != null
4    && request.resource.data.title is string
5    && request.resource.data.title.size() > 0
6    && request.resource.data.title.size() <= 200
7    && request.resource.data.body is string
8    && request.resource.data.body.size() <= 50000
9    && request.resource.data.author_id == request.auth.uid
10    && request.resource.data.keys().hasOnly(
11         ['title', 'body', 'tags', 'author_id', 'created_at']);
12}

Without rate limiting, any authenticated user can hammer your Cloud Functions thousands of times — running up your Firebase bill or spamming other users. Implement rate limiting using Firestore to track request counts per user. In your Cloud Function, before processing the request, check a rate_limits/{userId} document. If the request count in the last minute exceeds your threshold, return a rate limit error immediately. Use FieldValue.increment to update the counter atomically and set a Firestore TTL to auto-delete old rate limit documents. For RapidDev clients building payment apps, we recommend 10 requests per minute for financial Cloud Functions and 60 per minute for general data operations.

1// Cloud Function rate limiter middleware
2const admin = require('firebase-admin');
3
4async function checkRateLimit(userId, actionName, maxPerMinute = 20) {
5  const db = admin.firestore();
6  const key = `${userId}_${actionName}`;
7  const ref = db.collection('rate_limits').doc(key);
8
9  const now = Date.now();
10  const windowStart = now - 60 * 1000;
11
12  const result = await db.runTransaction(async (tx) => {
13    const doc = await tx.get(ref);
14    const data = doc.exists ? doc.data() : { count: 0, windowStart: now };
15
16    // Reset window if older than 1 minute
17    if (data.windowStart < windowStart) {
18      tx.set(ref, { count: 1, windowStart: now, expiresAt: new Date(now + 120000) });
19      return { allowed: true };
20    }
21
22    if (data.count >= maxPerMinute) {
23      return { allowed: false };
24    }
25
26    tx.update(ref, { count: admin.firestore.FieldValue.increment(1) });
27    return { allowed: true };
28  });
29
30  return result.allowed;
31}