你的 Flutter 应用在发布后泄漏了什么（以及如何在发布前捕获它）

Source: Dev.to

您花了数月时间构建 Flutter 应用。QA 已通过。用户喜欢它。您将其发布到生产环境。
随后一位安全研究员给您发邮件：“嗨，我在您的应用中发现了硬编码的 Firebase 密钥。”

攻击者在构建好的 Flutter 应用中能看到什么

当您编译 Flutter 应用时，生成的包不仅仅包含 UI 代码。以下内容可能会泄漏：

硬编码的机密信息

• 写入 Dart 代码中的 API 密钥
• Firebase 凭证（数据库 URL、API 密钥、项目 ID）
• OAuth 客户端密钥
• 第三方服务令牌

这些信息会在编译后仍然保留在最终构建产物中，任何人只要反编译应用都能读取。

Firebase 配置错误

• 未受限的数据库规则
• 公开的存储桶
• 缺少身份验证要求
• 客户端代码中包含的 Admin SDK 凭证

危险的权限

INTERNET                         (必需但常与风险权限一起出现)
READ_EXTERNAL_STORAGE / WRITE_EXTERNAL_STORAGE   (缺乏正当理由)
ACCESS_FINE_LOCATION            (在不必要时使用)
CAMERA / MICROPHONE              (会触发隐私警报)

生产环境中的调试构建

• 在 AndroidManifest.xml 中保留 debuggable=true
• 暴露开发环境的接口
• 含有堆栈跟踪的详细错误信息
• 调试符号使逆向工程更容易

为什么会出现这些问题

Flutter 的编译流程：

• Dart 代码 → 编译为原生代码
• 资源、配置、清单 → 原样打包
• 字符串、URL、密钥 → 常以可读形式保留
• Tree‑shaking 并不会移除硬编码的机密

即使代码已编译，反编译工具仍能提取：

• 资源文件
• Android 清单中的权限
• 编译后的字符串字面量
• 资源文件和配置

如何在发布前捕获这些问题

发布前安全检查清单

• 绝不硬编码机密 – 使用环境变量或安全保管库。
• 审计 Firebase 规则（假设您的密钥已经公开）。
• 检查 AndroidManifest.xml 中的调试标志和过多的权限。
• 从生产构建中剥离调试符号。
• 使用反编译工具自行测试应用。

自动化扫描

我在生产环境中意外泄露 Firebase 密钥后（真实故事——安全研究员发现了它）构建了 FlutterGuard。它会反编译您的 Flutter 应用并展示攻击者看到的内容：

• 硬编码的机密 / URL / Firebase 配置
• 危险的权限和调试构建
• 大约 3 分钟内生成的清晰、可操作的报告

优惠： 每天免费扫描 3 次，无需信用卡。

如果您使用了它，请告诉我一件可以改进的地方——我会在同一天内发布修复。

保持安全，安全发布。 🔒