FlutterFlow Security Guide: Firebase Rules, Auth, and Data Protection
FlutterFlow apps rely on Firebase for security. Learn how to configure Firestore rules, secure authentication, and prevent data breaches in your FlutterFlow app.
By Gabriel CA · Kraftwire Software
· 9 min readFlutterFlow makes mobile and web app development visual. But under the hood, your app's security depends entirely on Firebase, and most FlutterFlow builders do not configure it correctly.
This is not a criticism of FlutterFlow or Firebase. Both are capable platforms with solid security features. The problem is that those features require manual configuration, and FlutterFlow's visual builder cannot fully automate the security setup. If you do not take the time to configure Firebase security rules, your app ships with the database wide open.
The Firebase Security Gap
FlutterFlow generates Flutter code that connects to Firebase for authentication, database (Firestore), and file storage. Firebase provides powerful security features, but they require intentional setup that most builders skip.
The Number One Risk: Misconfigured Firestore Rules
Firebase Firestore rules control who can read and write data. The default rules in many FlutterFlow projects are dangerously permissive. They allow anyone to read and write everything in the database. This means anyone, not just authenticated users, can read and modify your entire database using nothing more than your Firebase project ID and the Firestore REST API.
**How bad is this really?** Consider what your database contains: user profiles with email addresses, order histories with payment details, private messages between users, business data you assumed was safe. With permissive Firestore rules, all of that is accessible to anyone who makes a simple HTTP request.
**The default rules often look like this:**
rules_version = '2';
service cloud.firestore {
match /databases/{database}/documents {
match /{document=**} {
allow read, write: if true;
}
}
}
That `if true` means everyone has full access to everything. You need to replace this with rules that check authentication and ownership.
Top FlutterFlow Security Risks
1. Insecure Authentication Configuration
FlutterFlow makes it easy to add a login screen, but the default configuration may not be secure enough for production:
**Brute force attacks** are possible if rate limiting is not enabled on your Firebase project. An attacker can try thousands of password combinations without being blocked.
**Weak password policies** allow users to set passwords like "123" or "password". Firebase lets you configure minimum password requirements, but you have to do it manually.
**Missing multi-factor authentication** for sensitive applications. If your app handles financial data, health records, or personal information, single-factor auth is not sufficient.
**Session management issues** with token expiry. Firebase tokens last one hour by default, but refresh tokens can last much longer. Understanding this lifecycle is important for security.
**How to fix it:**
Enable rate limiting in your Firebase project settings
Set minimum password length to 12 characters and require complexity
Implement MFA for apps that handle sensitive data
Configure appropriate session lengths and force re-authentication for sensitive operations
Enable Firebase's email enumeration protection to prevent attackers from discovering which emails have accounts
2. Exposed API Keys and Firebase Configuration
FlutterFlow apps embed Firebase configuration (API keys, project IDs, app IDs) in the client. While Firebase API keys are designed to be public (they are not secrets in the traditional sense), they still need to be restricted to prevent abuse:
**Set HTTP referrer restrictions** on your API key in Google Cloud Console so it can only be used from your domain
**Enable Firebase App Check** to prevent unauthorized apps and scripts from using your Firebase resources
**Never embed non-Firebase API keys** in FlutterFlow's custom code. If you need to call a third-party service, do it through a Cloud Function where the key stays on the server.
**Why API key restriction matters:** Without restrictions, anyone who copies your Firebase config (which is visible in your app's client-side code) can use it to make requests to your Firebase project. With App Check enabled, Firebase verifies that requests come from your actual app, not from a script or unauthorized application.
3. Insecure File Storage
Firebase Storage rules control who can upload and download files. The default rules are often too permissive, creating several risks:
**Anyone can upload files** to your storage bucket, which can be used for hosting malware, phishing pages, or illegal content on your domain
**No file size limits** means an attacker can upload massive files to run up your storage costs or overwhelm your infrastructure
**No file type validation** allows upload-based attacks where executable files are disguised as images
**Public read access to sensitive documents** means private files like invoices, contracts, or personal photos are accessible to anyone with the URL
**How to write proper Storage rules:**
rules_version = '2';
service firebase.storage {
match /b/{bucket}/o {
match /users/{userId}/{allPaths=**} {
allow read, write: if request.auth != null
&& request.auth.uid == userId
&& request.resource.size < 5 * 1024 * 1024
&& request.resource.contentType.matches('image/.*');
}
}
}
This restricts uploads to authenticated users, limits files to their own folder, caps file size at 5MB, and only allows image files.
4. Missing Input Validation
FlutterFlow's form widgets provide basic client-side validation (required fields, email format, etc.), but they do not automatically sanitize input. Without server-side validation:
Users can submit malicious data that your database stores without question
Script injection through text fields can affect other users who view that data
Extremely long inputs can cause display issues or performance problems
Special characters in user input can break queries or formatting
**How to fix it:** Add validation in your Firestore security rules and Cloud Functions. Firestore rules can check data types, string lengths, and required fields. Cloud Functions can perform more complex validation before writing to the database.
5. Missing Firestore Indexes and Query Restrictions
Without proper query restrictions in your Firestore rules, authenticated users might be able to run expensive queries that return large amounts of data or consume excessive read operations, running up your Firebase bill.
**How to fix it:** Use Firestore rules to restrict which queries are allowed. For example, require that queries include a filter on the user ID field, so users can only query their own data.
How to Secure Your FlutterFlow App
Step 1: Fix Your Firestore Rules
Replace the default permissive rules with specific, role-based access controls:
Users should only be able to read and write their own documents
Public data (like product listings) should be read-only for unauthenticated users
Admin operations should check for an admin role or custom claim
Write operations should validate data types and required fields
**Test your rules** using the Firebase Rules Simulator before deploying. Try accessing data as different user types (unauthenticated, regular user, admin) to verify that your rules work correctly.
Step 2: Enable Firebase App Check
App Check verifies that requests to your backend come from your actual app, not from a script or unauthorized tool:
Go to Firebase Console and open the App Check section
Register your app with reCAPTCHA Enterprise (for web) or DeviceCheck (iOS) or Play Integrity (Android)
Enable enforcement on Firestore, Storage, and Cloud Functions
Test that your app still works after enabling enforcement
App Check does not replace security rules. It adds an additional layer that makes it harder for attackers to interact with your Firebase resources directly.
Step 3: Restrict API Keys
In Google Cloud Console:
Go to APIs and Services, then Credentials
Click on your Firebase API key
Under Application restrictions, add your domain for web apps or your app's bundle ID for mobile
Under API restrictions, select only the Firebase APIs your app actually uses
Save and verify your app still works
Step 4: Secure File Uploads
Configure Firebase Storage rules to:
Require authentication for all uploads
Restrict uploads to the authenticated user's own folder
Limit file size (5 MB is reasonable for most apps)
Restrict file types to what your app actually needs (images, PDFs, etc.)
Set appropriate read permissions based on whether files should be public or private
Step 5: Enable Monitoring and Alerts
Set up Firebase budget alerts to catch unusual spikes in usage
Enable Cloud Logging to track authentication events and security-related activities
Monitor failed authentication attempts for signs of brute force attacks
Review Firestore usage metrics regularly for unexpected patterns
Step 6: Test with SimplyScan
Deploy your FlutterFlow app and scan it with [SimplyScan](https://simplyscan.io) to detect:
Exposed Firebase configuration that should be restricted
Publicly accessible Firestore endpoints
Missing security headers
Unprotected API routes
Client-side vulnerabilities that Firestore rules cannot prevent
Key Takeaways
Firebase security rules are not configured by default. This is the single most important thing to understand about FlutterFlow security. You must set them manually, and you must test them thoroughly.
Firestore rules are the number one cause of data breaches in FlutterFlow apps. Get these right and you eliminate the majority of critical vulnerabilities.
Enable App Check and restrict API keys to prevent unauthorized use of your Firebase resources. Test your rules with different user roles before launching. And scan your deployed app with [SimplyScan](https://simplyscan.io) to catch external vulnerabilities that security rules alone cannot prevent.
Related Guides
[No-Code Platform Security Guide](/blog/nocode-platform-security)
[Bubble Security Guide](/blog/bubble-security-guide)
[WeWeb Security Guide](/blog/weweb-security-guide)
[Xano Security Guide](/blog/xano-security-guide)
[Firebase Security Checklist](/blog/firebase-security-checklist)