FlutterFlow security guide: private APIs and data rules

By Thunkle · Platform references checked 19 September 2026

A FlutterFlow security review must follow the request from the shipped client to its backend. Page visibility, a private API setting and database rules protect different parts of that journey. None should be used as a shortcut for reviewing the others.

Begin by listing the Firebase, Supabase or custom services your project actually uses. Include mobile builds, web builds and backend functions in the scope where relevant. Our application security audit can review that complete path rather than only the visual builder.

Review the client and backend together

A developer should review what your FlutterFlow client can request, not just which pages it displays. That means checking private API configuration alongside database rules, storage access and any custom backend authorization. A mobile build and a web build may reach the same sensitive operation differently; a useful review includes the release paths your customers will actually use.

Request a paid FlutterFlow application security review for a developer-led audit covering the agreed clients and backend paths. Thunkle supplies evidence-backed findings and practical remediation guidance, with a free re-review of agreed fixes. Fix implementation can be added under a separate scope.

Understand what a private API call changes

FlutterFlow documents that private API calls run through Firebase Cloud Functions, with a separate option to require Firebase authentication. That is useful for keeping privileged provider credentials out of the client, but making a call private is not the same as defining every permitted business action. FlutterFlow API call documentation.

Confirm the deployed configuration, including whether authentication is required for the relevant call. Then ask which resources an authenticated caller may request and how usage is limited. An authenticated proxy that accepts arbitrary target records can still perform work the caller should not control.

Do not put privileged provider credentials in a custom action or client-side constant simply because it is convenient. A distributed mobile application is still a client. Treat embedded values according to their privileges, not whether they are easy to see in a browser.

Review database and storage rules independently

For each private record, identify the backend rule that constrains reads and writes. A FlutterFlow query that filters by the current user expresses intended behaviour; verify that the backend rejects access outside that scope too.

Review uploads and downloads separately from document or table permissions. A private profile may reference a file with a different access model. Define whether sharing expires and what should happen after an account is removed from a team.

Firebase public API configuration and Supabase public keys are not automatically leaked secrets. Privileged service credentials are different. The security question is the backend access available to each identity and the capabilities of the particular credential.

Test a synthetic field-service workflow

Imagine technicians submitting job photos. Each technician sees assigned jobs; a supervisor can reassign them; customers may view only the approved report. This is an illustrative test case, not a client disclosure.

In an authorized isolated environment, create synthetic jobs, harmless photos and dedicated accounts. Check:

• The assigned technician can submit a permitted update.
• A different technician cannot retrieve or alter the job.
• A technician cannot change the assignment through an underlying request.
• The supervisor can reassign the job and access changes as intended.
• The customer cannot download unapproved photos through their file URLs.

Inspect stored state after rejected writes and preserve successful allowed operations as controls. Do not involve real customer locations, photographs or notifications in routine testing.

Verify each environment and release artifact

FlutterFlow supports development environments mapped to separate Firebase or Supabase projects. Check the selected environment and the connections used by the actual release. FlutterFlow development environment documentation.

A test in the builder is not proof that the distributed mobile build points at the intended backend. Verify the build configuration, custom code, callback handling and provider modes for each target you release. Retain version identifiers so findings can be reproduced against the right artifact.

When permissions change, test both a fresh sign-in and the expected behaviour of an already signed-in client. Define server-side revocation expectations rather than relying on a refreshed screen to remove authority.

When to bring in an independent review

A review is useful when the application combines mobile clients, multiple roles, private uploads and server functions, or when a private API proxy mediates an expensive service. Ask for evidence of the tested paths and a clear account of any unavailable platform configuration.

Is “Make Private” enough to protect an API?

It changes where the call executes. You still need to check caller authentication, resource authorization, accepted inputs and abuse controls for the intended use.

Do you need customer data for the audit?

Normally the test should use dedicated accounts and synthetic fixtures. Necessary access and exceptions are agreed before work begins. No audit can guarantee the absence of all vulnerabilities.

Get a security audit quote with your backend, release targets, roles and sensitive workflows. We define the scope and provide prioritized findings with remediation guidance. Implementation can be scoped separately, with a free re-review of agreed fixes. Do not send credentials in the enquiry.