Inventory what the client contains
Review Dart constants, bundled assets, Android resources, native plugins and generated configuration. A secret moved from Dart to a native library is still shipped to the user.
The Flutter obfuscation guide states the scope of its protection. Use Android security guidance for platform storage, networking and component exposure.
Separate identifiers from credentials
| Value | Appropriate treatment |
|---|---|
| Public project identifier | Validate configuration and backend controls |
| User session token | Minimize exposure and use appropriate storage/lifetime |
| Service-account private key | Keep off the client entirely |
| Third-party privileged API key | Move privileged operation behind controlled backend access |
A scan finding a string is a reason to classify it, not automatically a confirmed vulnerability.
Review plugins as native code
A Flutter package can add Android permissions, services, providers and SDK behavior. Inspect the merged manifest and actual dependency inventory rather than reviewing only Dart source.
Remove unused plugins and verify the current publisher, maintenance state and documented data handling of retained dependencies.
Test boundaries, not only screens
Test unauthorized requests, another user's resource ID, revoked permission, expired token and invalid input. A polished UI can still call an overly permissive backend.
Keep logs and crash reports free of tokens and private content. Debug conveniences should not silently survive into the release variant.
Preserve release diagnostics
Archive obfuscation symbols and native symbols where applicable, then verify readable crash diagnostics from an optimized test release.
APKLint's Flutter APK Analyzer and security tools can support package inspection. They do not prove backend authorization, runtime behavior or resistance to every attack. A useful audit ends with specific verified controls and clearly scoped unresolved risks, not a single “secure APK” label.
Test account ownership beyond the Flutter screen
Imagine a document app whose UI lists only the current user's files, but its server accepts any supplied document identifier. In an authorized test environment, create synthetic accounts A and B and attempt to request B's document through A's authenticated session. The server must enforce ownership regardless of what the Flutter list screen displays. Hiding an identifier or obfuscating a Dart class does not supply that control.
The Flutter obfuscation documentation states the limited protection offered by name transformation. Keep privileged server credentials out of Dart constants, Android resources and native plugin binaries alike. Public project configuration needs its own restriction and authorization review rather than being automatically classified as a private key.
Review the Android surface contributed by plugins
A file-sharing or authentication plugin can introduce providers, activities, permissions and Android libraries. Inspect the merged release manifest and dependency inventory after plugin changes. Verify the feature's actual behavior with malformed input, revoked access and a cancelled operation. Reviewing only the Dart package API can miss the platform boundary that performs the work.
For stored session data, choose a supported storage design with explicit sign-out, expiry and recovery behavior. Test account switching so the next account cannot see a previous account's cached content. Avoid logging tokens or private documents during error handling, including crash reports collected from optimized releases. Review screenshots and background task notifications for the same account-bound disclosure problem.
Keep findings scoped to the evidence: an embedded privileged credential, an unauthorized test request that succeeds, or an exported component accepting unintended input. Separate those confirmed defects from package signals requiring investigation. Retain the exact release artifact and the minimum redacted evidence needed to reproduce each issue. Recheck the repaired request and a legitimate authorized request so the fix does not merely disable the product. A useful review follows data through client, platform plugin and service boundaries; an attractive Flutter screen or an obfuscated package is not a complete security assessment.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
