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

Published: (December 30, 2025 at 08:09 AM EST)
2 min read
Source: Dev.to

Source: Dev.to

Cover image for 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, the resulting package contains more than just UI code. Here’s what can leak:

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 the final build, readable by anyone who decompiles the app.

Firebase Misconfigurations

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

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              (raise privacy flags)

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:

  • Dart code → compiled native code
  • Assets, configs, manifests → bundled as‑is
  • Strings, URLs, keys → often remain in readable form
  • Tree‑shaking doesn’t remove hardcoded secrets

Even though the code is compiled, 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

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

Automated scanning

I built FlutterGuard after I shipped my Firebase key in production (true story—security researcher found it). It decompiles your Flutter app and shows 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.

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

Stay safe. Ship secure. 🔒

Back to Blog

Related posts

Read more »