DEV Community

Cover image for What Your Flutter App Leaks After Release (And How to Catch It Before Launch)
Flutter Guard
Flutter Guard

Posted on

What Your Flutter App Leaks After Release (And How to Catch It Before Launch)

You spent months building your Flutter app. QA passed. Users love it. You ship to production.

Then a security researcher emails you: "Hey, I found your Firebase keys hardcoded in your app."

What Attackers See in a Built Flutter App

When you compile a Flutter app, you're creating a package that contains more than just your UI code. Here's what can leak:

1. Hardcoded Secrets

  • API keys baked into Dart code
  • Firebase credentials (database URLs, API keys, project IDs)
  • OAuth client secrets
  • Third-party service tokens

These survive compilation and end up in your final build, readable by anyone who decompiles your app.

2. Firebase Misconfigurations

  • Unrestricted database rules
  • Public storage buckets
  • Missing auth requirements
  • Admin SDK credentials in client code

3. Dangerous Permissions

  • INTERNET (required but often paired with risky perms)
  • READ_EXTERNAL_STORAGE / WRITE_EXTERNAL_STORAGE without justification
  • ACCESS_FINE_LOCATION when unnecessary
  • CAMERA / MICROPHONE that raise privacy flags

4. Debug Builds in Production

  • Leaving debuggable=true in AndroidManifest.xml
  • Exposing dev endpoints
  • Verbose error messages with stack traces
  • Debug symbols that make reverse engineering easier

Why This Happens

Flutter's compilation process:

  1. Dart code → compiled native code
  2. Assets, configs, manifests → bundled as-is
  3. Strings, URLs, keys → often remain in readable form
  4. Tree-shaking doesn't remove hardcoded secrets

You think you're safe because the code is compiled. But decompilation tools can extract:

  • Asset files
  • Android manifest permissions
  • Compiled string literals
  • Resource files and configs

How to Catch These Before Release

Pre-release security checklist:

  1. Never hardcode secrets—use environment variables or secure vaults
  2. Audit Firebase rules (assume your keys are public)
  3. Review AndroidManifest.xml for debug flags and excessive permissions
  4. Strip debug symbols from production builds
  5. Test your own app with decompilation tools

Or scan it automatically:
I built FlutterGuard after I shipped my Firebase key in production (true story—security researcher found it). It decompiles your Flutter app and shows you exactly what an attacker sees:

  • Hardcoded secrets/URLs/Firebase configs
  • Dangerous permissions and debug builds
  • Clear, actionable report in ~3 minutes

Offer: 3 free scans/day, no card required → flutterguard.dev

If you try it, tell me one thing to improve—I ship fixes same-day.


Stay safe. Ship secure. 🔒


Top comments (0)