Is FlutterFlow Safe? Your Firebase Rules Are the Real Attack Surface
FlutterFlow apps are as secure as their Firebase rules. Test-mode rules in production hand your database to anyone · and the config being public is by design.
By Daniel A · Kraftwire Software
· 6 min readKey Takeaway
Yes, FlutterFlow is safe · the builder produces legitimate Flutter apps and its own platform is not the weak point. Your Firebase security rules are. A FlutterFlow app is exactly as secure as the rules on its Firestore database and storage buckets, and the single most common failure is shipping test-mode rules that let anyone on the internet read and write everything.
What FlutterFlow Actually Is
FlutterFlow is a visual builder that generates real Flutter code for iOS, Android, and web apps. For the backend it leans on Firebase by default, with a Supabase integration as the alternative. That architecture decides where security lives: the app you ship is a client, and clients cannot be trusted. Every meaningful protection sits server-side, in Firebase security rules or Supabase Row Level Security.
This is the core mental shift for FlutterFlow builders. In a traditional stack, your server code stands between users and the database. In a FlutterFlow app, the user's device talks to Firestore directly, and the rules are the only bouncer at the door. Get the rules right and the rest of this article is maintenance. Get them wrong and nothing else matters.
The Short Answer: Yes · With Conditions
- FlutterFlow the platform · the editor, code generation, build pipeline. Solid, and not your attack surface.
- Your Firebase rules, storage rules, and any secrets in custom code · this is the entire game.
Here are the vulnerability classes that actually show up in FlutterFlow apps.
1. Test-Mode Firestore Rules in Production
Firebase projects created in test mode start with rules that allow everything, so development is frictionless:
Test mode is supposed to expire, but plenty of builders extend it or copy the pattern to "fix" permission errors during development, and then launch. The result: anyone with your project ID can read your entire database, modify records, and delete collections. No exploit needed · this is the documented behavior of the rules as written.
How to fix it
- Require authentication as the floor:
allow read, write: if request.auth != null; is the minimum, not the goal.
- Scope access per collection to the record owner:
allow read, write: if request.auth.uid == resource.data.uid; for user-owned data.
- Never "fix" a permission-denied error by loosening rules globally. Fix the specific rule for the specific collection.
- Work through our Firebase security checklist before launch; it covers Firestore, Auth, and Storage rules in order.
2. Misreading the Public Firebase Config
Open any FlutterFlow web app and you will find a Firebase apiKey, project ID, and sender ID in the source. Scanners and worried developers flag this constantly. Here is the accurate reading: the Firebase web config is public by design. It identifies your project so the SDK knows where to connect · it does not authorize anything. Security lives entirely in your rules.
This misunderstanding causes damage in both directions. Some builders panic and burn days trying to hide a value that cannot and need not be hidden. Others hear "the key is fine" and conclude the whole setup is fine, while their rules sit in test mode. The config being public is exactly why the rules carry all the weight.
How to fix it
- Do not waste effort obfuscating the Firebase config. Spend that effort on rules.
- Do lock down what the config points at: rules, App Check if you want an extra layer, and per-service restrictions on the key in Google Cloud Console.
3. Secrets in Custom Actions and Custom Code
FlutterFlow's escape hatch is custom actions and custom functions written in Dart. The moment a builder needs to call OpenAI, Stripe, or a private API, the temptation is to paste the secret key straight into the action. That key compiles into the app binary and ships to every user. Mobile binaries are not safes · extracting strings from an APK is a beginner exercise.
How to fix it
- Route secret-bearing calls through a backend: Cloud Functions for Firebase, a Supabase edge function, or any small server you control. The app calls your endpoint; your endpoint holds the key.
- Search your custom code for
sk_, Bearer, and apiKey before every release.
- Already shipped a secret inside a binary? Rotate the key now · the guide to fixing exposed API keys covers rotation order so you do not break production while you do it.
4. Missing RLS on the Supabase Integration
FlutterFlow's Supabase integration hands you the same contract as Firebase, with different names: the anon key in your app is public by design, and Row Level Security is the enforcement layer. Tables created quickly during development often have RLS disabled, which means anyone with your project URL and anon key · both extractable from the app · can read and write those tables directly through the REST API.
How to fix it
5. Forgotten Storage Rules
Firestore gets the attention; Firebase Storage gets the breach. Profile photos, uploaded documents, and chat attachments live in buckets with their own rules, and test-mode storage rules make every file publicly readable and writable. Uploaded ID documents in an open bucket is the nightmare version, and it happens.
How to fix it
- Apply the same owner-scoped pattern to storage paths: users read and write only their own folder.
- Check download URLs: Firebase's token-based URLs are shareable by design, so do not treat them as access control for sensitive files.
When NOT to Worry
- The Firebase config in your source. Public by design, as covered above. Flag rules, not config.
- Prototype projects with seed data. Test mode on a database full of lorem ipsum is a workflow, not an incident. Fix it before real users arrive.
- Read-only public content. Rules that allow public reads on a content catalog are a choice, not a hole · as long as writes stay locked.
How to Verify Before You Launch
Test your rules from outside your own app: the Firebase console's Rules Playground simulates requests, and an unauthenticated REST call to your Firestore or Supabase endpoint tells you the truth in one line. Repeat the test as a logged-in user against another user's document, because "authenticated users can read everything" is the second most common rules failure after test mode. And retest after every schema change · new collections do not inherit the care you put into old ones. Then run the broader sweep · SimplyScan runs 51+ checks across 14 categories, the free scan covers exposed secrets, frontend issues, Supabase RLS, and speed, and the FlutterFlow scanner page details what we test on this stack. The full FlutterFlow security guide is the step-by-step hardening companion.
Before your FlutterFlow app meets real users, run a free security scan and find out in thirty seconds whether your rules are carrying their weight.