如果你正在规划APP开发，或者产品已经上线但用户隐私保护总被合规部门挑刺，那今天这篇就是为你准备的。干了11年软件外包，见过太多团队在数据安全上翻车——不是技术不行，而是把“加密”想得太简单，把“合规”当成应付审查的纸面作业。今天不说空话，直接讲我们自己在项目中踩过的坑和填坑的套路。

HTTPS加密只是入门，证书跟API还得单独加固

坦白讲，很多团队觉得上了HTTPS就万事大吉，结果被抓包工具一看，请求和响应清清楚楚。为什么？因为HTTPS只保护传输通道，但证书验证不严或API设计有漏洞，照样裸奔。我们给一家贵州餐饮企业做APP开发时，就发现他们之前用的第三方登录接口没有做证书锁定，中间人攻击一秒破解。后来我们强制做了SSL Pinning，并且把所有敏感接口的响应体用AES-256再次加密，钥匙存在安全区域。这么搞之后，就算HTTPS被绕过，数据也是乱码。

还有一件事——直接传明文用户ID。常见做法是URL里带userId，但这样太容易被篡改。正确的做法是用一次性的token绑定用户会话，并且每次请求都校验签名。我们项目里的标准是：所有非公开接口必须带sign参数，由前端用私钥对参数排序后HMAC加密，后端验签才放行。这个细节，很多初创业者根本想不到。

本地缓存是数据泄露的重灾区，别把用户信息当Cookie存

移动端本地存储太方便了，不少开发者图省事直接写SharedPreferences或UserDefaults。但说真的，这些东西明文暴露在文件系统里，root或越狱后随便看。我们遇到过客户自己找人开发的APP，把银行卡号和CVV码都明文存本地，吓得我们立马建议用户注销那个账号。后来在重写时，推荐使用iOS的Keychain和Android的EncryptedSharedPreferences，并且对敏感字段用key(APP开发可参考)做分段存储——就算拿到数据库，没有业务逻辑拼不回去。

还有那些第三方日志统计SDK，默认会收集大量设备信息。很多开发者勾了“允许采集”就没管过，结果某次合规审计被查出违规收集MAC地址和IMSI。我们在做APP开发时，会强制要求所有SDK配置为最小采集模式，并在用户同意隐私协议前禁止任何网络请求。这个开关，能避免90%的隐私雷。

隐私合规不是写个弹窗就够了，场景授权才是真合规

2024年监管力度，大家都懂。很多人以为加个“同意”按钮就合规了，但真实场景是：用户下载后首次打开，一口气弹三四个权限申请（位置、相册、通讯录），用户点了拒绝，APP直接闪退或功能不可用——这种操作，一举报一个准。我们给某贵州客户重构APP时，把权限请求全改成了“按需申请”：用户要用扫码功能才弹相机权限，要用上传图片才弹存储权限。并且所有敏感行为（如收集设备ID）都在隐私政策里写清楚使用目的。

说个血泪教训：客户被用户投诉说隐私泄露，监管要求提供30天内所有数据外发记录。他们之前没做，差点被罚。后来我们帮他们集成了合规日志系统，每次加密传输后都记录时间、目标地址、数据摘要（不存原文），存一年备查。这个做法已经成了我们APP开发的标准交付项。

传输协议不要只用HTTPS，混合加密加本地验签更安全

坦白讲，如果你做的是金融、医疗类APP，单靠HTTPS还是不够。我们有个客户做在线问诊，需要传输病历图片和诊断报告。HTTPS只保传输中，但服务器端如果被拖库，数据还是明文。所以我们做了端到端加密：客户端用RSA公钥加密数据，服务器只有私钥能解。即便CDN节点或反向代理被黑，拿到的也是密文。同时，所有图片上传前在客户端计算哈希，服务器存哈希比对，防止传输过程中被篡改。

再来说说WebSocket的长连接，也很危险。很多人用ws协议，数据包直接裸奔。我们一律强制wss，并且对业务数据再做一层轻量加密（比如XOR+Base64，防止明文嗅探）。别嫌麻烦，真实案例就发生在某社交APP上，用户聊天记录被抓包软件一网打尽，最后公关费花了几百万。

常见问题

问题一：什么样的企业适合做APP开发？

说白了，有高频使用场景、需要利用手机硬件（摄像头、GPS、蓝牙）、或对体验要求高的企业，