FlutterFlow App Penetration Testing
FlutterFlow builds the screens and logic, but access control lives entirely in your Firebase or Supabase rules. We test what those rules, your API keys and your custom code actually allow. CREST-certified testers, fixed price from £2,270 for a 2-day single-app scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
FlutterFlow’s default rule for a brand new Firestore collection sets Create and Read to Everyone. A collection flagged as holding private data only gets a warning, not an enforced rule change.
FlutterFlow assembles the screens, but your Firebase rules, Supabase policies and custom code still decide what the app can reach
Every Firestore or Supabase action you drag into a FlutterFlow app calls the database straight from the device, using the project’s own API key or anon key. Firebase’s own documentation is explicit that this key is public by design and is not what keeps your data safe; that job belongs to the Firestore and Storage rules you deploy, or the row level security policies behind a Supabase table. A brand new FlutterFlow collection defaults to Create and Read access for Everyone, and the platform’s own warning for a collection holding private data is a prompt to change the rule, not a block on the rule you left in place.
FlutterFlow’s API Calls run directly from the device unless you turn on Make Private, so any header, token or key on that call ships inside the compiled app or shows up in a browser’s network tab on a published web build. Enabling it moves the call into a Cloud Function inside your own Firebase project, but FlutterFlow’s own guidance is that a private call still exposes its key if that key is read from the frontend, such as a Remote Config value, rather than set inside the function itself. We test which calls are actually private, and where each secret is really coming from.
The parts of the app that sit outside FlutterFlow’s generated screens carry the same risk they would in any other framework. A deep link that opens a page using the page-parameter syntax FlutterFlow builds on can address a specific record directly, a Custom Action can carry a secret or a pub.dev package the generated code never uses, and a multi-tenant app needs its organisation check written into the rules themselves, since a check that lives only in the UI still lets a crafted request past it. We test each of these the way a real user, or one who changed a parameter, actually would.
SCOPE
What we pen test on a FlutterFlow application
Firestore and Storage Rule Defaults
FlutterFlow’s default rule for a brand new Firestore collection allows Create and Read by Everyone, and a collection flagged as holding private data only shows a warning until you rewrite the rule yourself. We test the rules and Storage bucket rules you actually deployed, not the warning that told you to write them.
Supabase Row Level Security Coverage
FlutterFlow’s Database Actions query and write to your Supabase tables using the project’s anon key straight from the device, so any table without row level security enabled, or with a policy that does not cover every operation, is reachable through that key. We test RLS coverage across select, insert, update and delete for each table your app uses.
Private API Calls and Where Keys Actually Live
An API Call left off Make Private runs from the device, so any header, token or key on it ships inside the compiled app or shows up in a browser’s network tab. Turning Make Private on moves the call into a Cloud Function in your Firebase project, but a private call still leaks its key if that key is read from the frontend rather than set inside the function; we test which is actually happening on each call.
Custom Actions, Custom Functions and pub.dev Packages
Custom Actions and Custom Functions are Dart code that runs on the device, including any pub.dev package or secret written into them, so anything hardcoded there ships with the app the same way a client-side value would. We review and test what these add beyond FlutterFlow’s own generated actions.
Cloud Functions and Edge Functions
Private API calls, callable Cloud Functions and Supabase Edge Functions all run as server-side code inside your own Firebase or Supabase project rather than FlutterFlow’s infrastructure. We test the authentication and input validation inside that code directly, since a function reachable without a valid session bypasses every rule you wrote for the client.
Authentication Flow and Token Handling
Whether your app signs users in through Firebase Authentication, Supabase Auth or a JWT your own backend issues, we test how the session is verified, whether password reset and account actions are gated to the signed-in user, and how an anonymous account is upgraded to a full account without losing or leaking its data.
Deep Link and Page Parameter Handling
FlutterFlow’s routing lets a page take a parameter straight from a deep link, such as profilePage/:profileId, so the link itself can address a specific record. We test whether reaching a page that way still enforces the same checks as reaching it through normal in-app navigation, across the iOS, Android and web builds a single FlutterFlow project can ship.
Multi-Tenant Data Isolation
Where the app serves more than one customer organisation from shared Firestore collections or Supabase tables, we test whether the organisation a request acts for comes from the rules and RLS policies themselves, or only from a filter the interface applies, since a check that lives only in the UI still lets a crafted request past it.
Web Build Exposure
Publishing a FlutterFlow project to web sends the same API calls, custom code and Firebase or Supabase configuration to the browser that the compiled mobile app carries, but a browser’s network tab and page source make it easier to inspect. We test what a visitor to the published web build can actually extract.
Native Storage and Device-Level Code
Where a Custom Action stores a token or session using a native package, or adds a native module beyond FlutterFlow’s generated code, we test whether that storage and any device-level check hold up the same way on both Android and iOS.
OUR PROCESS
FlutterFlow App Penetration Testing: From Scope to Attestation
Map the FlutterFlow Build
We catalogue every Firestore collection, Supabase table, API call and Custom Action or Function in scope, plus which backend, Firebase, Supabase or a custom endpoint, your authentication runs against.
Rule and Policy Review
We read the deployed Firestore and Storage rules or Supabase RLS policies alongside the API calls marked private, so we know what should be enforced before we test what actually is.
Manual Testing Across Roles and Platforms
CREST-certified testers exploit the app the way a real user would, across web, iOS and Android builds where the project targets more than one, with and without authentication.
Reporting and Retest
You get a technical report with CVSS scores and reproduction steps, a walkthrough call, a free retest once fixes are deployed, and an attestation letter for auditors.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST FlutterFlow pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent FlutterFlow App Penetration Testing Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
2 to 3 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote3 to 4 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test FlutterFlow For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From FlutterFlow App Penetration Testing
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need to test our FlutterFlow app?
At least one authenticated test account for every role your app defines, plus an anonymous session if you allow anonymous sign-in. Read access to your deployed Firestore or Storage rules, Supabase RLS policies, or Custom Authentication endpoint speeds up testing but is not required for a black-box test. For any API call marked private, a test credential is enough; we do not need your production secret.
Will testing touch our live data?
We test whichever Firebase or Supabase project you give us access to. If that has to be production, we agree exclusions upfront, such as destructive writes, deletes and outbound emails, and where possible we ask for a staging project instead.
How long does a FlutterFlow app test take?
A single app sits in our 2-day single-app scope, with a report typically landing around 5 working days after kickoff. An app with more roles, a multi-tenant structure or several third-party integrations moves into a wider scope with more testing days.
Do you test the app the same way if it runs on Supabase instead of Firebase?
Yes. We test whichever backend your FlutterFlow project actually connects to: Firestore and Storage rules for Firebase, row level security policies for Supabase, or the endpoints your own server exposes for Custom Authentication. The private API call, Custom Action and Custom Function testing is the same either way.
Is the web build in scope if we publish to web as well as mobile?
Yes, by default, since a published FlutterFlow web build sends the same API calls, custom code and backend configuration to the browser that the compiled app carries. Tell us during scoping if you only want the mobile builds tested.
What is out of scope?
FlutterFlow’s own builder, editor and account infrastructure are out of scope, along with the underlying Firebase or Supabase platform’s own infrastructure. We test the app you built: its rules, policies, API calls and custom code.
Do you need our source code?
No. Testing runs black-box against the running app and its backend by default. Read access to your Firestore or Storage rules, RLS policies, or the code behind a Custom Action or Cloud Function is optional and mainly speeds up triage on specific findings.
Do FlutterFlow, Firebase or Supabase have a customer penetration-testing policy we need to follow?
FlutterFlow does not host your backend, so the policy that actually applies is your Firebase or Supabase provider’s. Google Cloud, which hosts Firebase, states that you do not need to notify them before testing your own project, provided you stay inside that project and within their acceptable use terms. Supabase’s own security guidance asks you to notify security@supabase.com before running an automated scanner and to keep any testing to your own project, and a self-hosted Supabase database carries no such vendor rule at all. We confirm the exact terms for your specific setup during scoping.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your FlutterFlow app
FlutterFlow builds the screens and logic, but access control lives entirely in your Firebase or Supabase rules. We test what those rules, your API keys and your custom code actually allow. CREST-certified testers, fixed price from £2,270 for a 2-day single-app scope, quoted within 24 hours.
