iOS 敏感密钥泄漏怎么防？我踩了三个坑才找到正确姿势
type
status
date
slug
summary
tags
category
icon
password
wechat_gate
做了一个语音转录 App，上线前做安全自查，发现一件让我背脊发凉的事：
把 ipa 包解压，进入
Payload/SpeechNote.app/，打开 Config.plist，QCloud 的 SecretId、SecretKey、SiliconFlow 的 API Key、Groq 的 API Key……全在里面，明文，清清楚楚。任何人只要下载我的 App，花三分钟就能把这些密钥拿走。
这篇文章记录我怎么解决这个问题的——包括走了哪些弯路，最后怎么用一个 20 行的 Cloudflare Worker 把问题收掉。
为什么 Config.plist 存密钥是个定时炸弹
很多 iOS 开发者的第一反应是「放 plist 不是挺方便的吗，我加 .gitignore 了啊」。
问题不在 Git，在包体。
App Store 审核通过之后，用户下载的 ipa 就包含了你所有的本地文件。
Config.plist 会原封不动打进去。只需要：或者更暴力一点：
AKID 开头的字符串直接出来，那是腾讯云 SecretId 的格式。这不是假设的风险，是实实在在的攻击面。竞争对手、薅羊毛的人、安全研究员，任何人都能做到。
第一个方案：全代理
一开始我想得很美：用 Supabase Edge Functions 做代理，密钥存在 Supabase 的 Secrets 里，App 永远不知道密钥是什么。
理论上完美——密钥永不离开服务端，哪怕运行时抓包也拿不到真正的 API Key。
然后我碰到了现实。
问题一：QCloud 用的是实时流式 SDK。
当前的实现是
QCloudRealTimeRecognizer，边录音边识别，实时出字幕。要把这个接入代理，要么做 WebSocket 中继（Supabase Edge Function 对长连接支持有限制），要么把 QCloud 改成批量模式——录完再上传，等结果。改成批量，用户体验直接退化：实时字幕消失，变成「录完等待」。
问题二：音频文件太大。
1 小时录音，音频文件轻松几十 MB。Supabase Edge Function 请求体默认限制 6MB，超了就得先上传到 Supabase Storage，再让 Edge Function 去读，再转发给 ASR 服务……
整个流程变成了：
为了保护密钥，把整个转录链路都改了。代价太大。
第二次思考：威胁模型对了吗？
我停下来想了一个问题：我真正想防的是什么？
- 防止密钥被静态分析从 ipa 里提取（拆包就能拿到）
- 还是防止运行时被抓包截获（Charles、mitmproxy）？
这两个是不同的威胁，对应不同的防护成本：
威胁 | 防护手段 | 代价 |
静态分析提取 | 运行时下发密钥 | 低 |
运行时抓包 | 全代理，密钥永不到设备 | 高 |
对于一个独立开发的转录 App，主要风险是：竞争对手解包、恶意用户批量薅 API 配额。这些都属于静态分析场景。
运行时抓包需要在目标设备上安装证书，门槛高得多，不是主要威胁。
结论：防静态提取就够了，不需要全代理。
最终方案：Cloudflare Worker 运行时下发
思路很简单：
密钥不打进 ipa，App 启动时从服务端拿，存在内存里，不写磁盘，不写 Keychain，进程结束就没了。
ipa 里只有两样东西：
- Cloudflare Worker 的 URL（不敏感）
- 一个轻量
APP_TOKEN（只能换来一次配置数据，不是 API Key 本身）
转录流程完全不变：QCloud 实时流、SiliconFlow 批量、Groq 批量，音频直接打到 ASR 服务，没有中转，没有大小限制。
实现细节
Cloudflare Worker（20 行 JavaScript）
注意：Dashboard 内置编辑器不支持 TypeScript，要用 JavaScript。
密钥全部存在 Cloudflare Dashboard → Settings → Variables and Secrets，类型选 Secret（加密存储，部署后不可读出）。
iOS — ConfigManager 新增 fetchRemoteConfig()
重试 3 次，失败就把
isTranscriptionAvailable 置为 false，转录功能降级，不崩溃。iOS — SceneDelegate 启动序列
原来的启动：
改后：
关键顺序：fetchRemoteConfig 必须在 initializeSDKsAfterConsent 之前，否则 SDK 初始化时密钥还是空的。
踩坑记录
坑一：Dashboard 编辑器不支持 TypeScript
index.ts 直接粘进去，部署报错：原因：
interface Env { ... } 里的 interface 是 TypeScript 关键字，JavaScript 严格模式里是保留字。解决：删掉
interface Env 那段类型声明，改成纯 JavaScript，函数签名从 async fetch(request: Request, env: Env) 改成 async fetch(request, env)。坑二：Rate Limiting 在 workers.dev 上不可用
我以为 Worker Settings 里有 Rate Limiting 开关，找了半天没找到。
实际情况：Cloudflare 的 WAF Rate Limiting 需要绑定自定义域名，
workers.dev 子域名不支持。要在 workers.dev 上做限速，只能在 Worker 代码里自己实现（需要 Durable Objects，复杂很多）。对于这个场景，
APP_TOKEN 验证已经够用了——没有 token 的请求直接 401，有 token 的请求来源是自己的 App。可以接受。坑三：Xcode 项目里有测试文件夹，但没有 Test Target
SpeechNoteTests/ 目录存在，SpeechNoteTests.swift 也在，但 project.pbxproj 里只有一个 Native Target（主 App），根本没有 Unit Test Target。直接在目录里创建测试文件是跑不起来的。需要在 Xcode 里 File → New → Target → Unit Testing Bundle，重新建一个 test target，再把测试文件加进去。
坑四：单例状态污染跨测试用例
ConfigManager 是单例，private init()。写单元测试时发现：测试 A 成功拿到密钥，设置了 qcloudSecretID = "q-id"；测试 B 测试失败场景，只断言 isTranscriptionAvailable == false，但 qcloudSecretID 里还残留着 "q-id"，后续加其他断言就会出问题。解决：在
ConfigManager 里加一个仅供测试调用的 resetForTesting() 方法，在每个测试用例的 setUp() 里调用，每次清空内存状态。这套方案能防什么，不能防什么
说清楚边界很重要，不要有虚假的安全感。
能防： 静态分析，解包 ipa 直接读取，二进制扫描工具。这是最常见的密钥泄漏方式。
不能防： 运行时抓包。有人在目标设备上装了代理证书，可以看到 App 从 Worker 拿到的密钥。理论上存在，实际上门槛高，对独立 App 不是主要威胁。
能做到： 密钥轮换不需要发版。直接在 Cloudflare Dashboard 改 Secret，几秒钟生效，全量用户同步，不用等 App Store 审核。
对于大多数独立开发的 App，这个方案的安全性和复杂度比是很划算的。
2026.03.24 17:02
沪 · 赵巷KFC
📌 声明：本文由 AI 辅助完成