最近，越来越多的小程序因个人信息保护不当被监管通报。通报中常见的问题包括：在App首次运行时未通过弹窗等明显方式提示用户阅读隐私政策，未在征得用户同意后才开始收集个人信息或打开可收集个人信息的权限，未向用户提供撤回同意收集个人信息的途径、方式等问题，这些问题都可以从普通用户视角轻易识别，但是有一个问题需要一些技术手段才能确认：未采取相应的加密、去标识化等安全技术措施。

小程序作为连接企业与用户的主要入口，承载了大量的个人信息和交易数据。其实检测机构并不需要发动复杂攻击，仅仅通过抓包工具+模拟普通用户操作、抓取网络流量、检查接口响应，就能轻易发现企业是否采取了必要的安全措施。

本文将结合近期通报案例，梳理监管常见的黑盒观察手段，并分析小程序在传输、存储和接口设计中容易被忽视的风险点，帮助大家提前自查，避免踩中红线。

在不需要被检查企业配合下，监管机构可以有以下手段：

1. 网络抓包/流量分析

原理：小程序与服务端通信时，所有HTTP请求都经过设备或网络。检测方可以使用官方提供的调试工具（微信开发者工具）或网络代理工具（如Fiddler、Charles）抓包，模拟用户环境，抓取请求数据。

发现点：

  • 数据是否通过HTTP 传输（明文）。

  • 即便是HTTPS，敏感字段（身份证号、手机号、银行卡号等）是否直接明文出现在请求体。

  • 数据格式是否仅是Base64/URL 编码（属于可逆编码，不算加密）。

结论：如果肉眼可直接识别敏感信息，就会被认定“未采取加密措施”。

2. 客户端存储检查

  • 看小程序本地缓存(wx.setStorage) 是否直接存储明文用户标识、token、敏感信息。

  • 发现点：如果能直接读取明文数据，而不是密文或脱敏值，说明缺少本地加密。

3. 接口/响应内容检查

  • 用测试账号触发关键业务流程，观察后台响应。

  • 如果数据库返回或接口响应中包含完整身份证号/手机号/邮箱→ 缺乏去标识化或最小必要原则。

二、再技术一点来解释检测机构怎么通过网络抓包发现未加密、为什么能判定未加密、常见误区、怎么修，并给出可落地的自查清单与小示例。

1、明文传输的敏感字段可读 ⇒未加密

（1）检测人员是怎么“发现”的

  • 在手机/模拟器上装好代理（Charles/Burp/Fiddler），安装根证书后，代理可解密HTTPS 流量（合法MITM）。

  • 触发关键流程（登录、实名认证、绑定银行卡、下单…），在抓包工具里查看请求/响应 的 Header 与Body。

他们会搜索/匹配常见敏感数据特征：

  • 手机号：^1[3-9]\\d{9}$

  • 身份证：^\\d{6}(19|20)\\d{2}(0[1-9]|1[0-2])(0[1-9]|[12]\\d|3[01])\\d{3}(\\d|X)$

  • 银行卡：通过Luhn 校验 快速判断

  • 姓名、地址、邮箱、定位坐标、精确时间戳、设备标识（IMEI/IDFA等）

（2）为什么能判定“未加密”

  • 抓到的字段可直接阅读、可正则匹配、可通过校验算法（如Luhn）验证真伪，这等同于明文。

  • 编码不等于加密：Base64/Hex/URL encode 只是换个表示法，抓包工具一键可解码。

  • 脱敏不等于加密：如 138****1234 只是显示层遮蔽；传输里若仍是明文完整值，一样判定未加密。

（3）正确姿势（字段级加密+ 完整性保护）

  • 用AES-GCM对敏感字段加密（对称密钥短期、动态下发），并携带 iv 与 tag。

  • 用RSA/ECC 公钥加密本次会话用的AES 密钥（密钥包裹/envelope）。

  • 对整个消息做签名/HMAC，防止被篡改与重放。

（4）常见误区

  • “我们已经HTTPS 了，就不用字段加密” → 不总是足够（见下面部分的“TLS 终止/日志”）。

  • “我们做了Base64/自定义混淆” → 仍是明文范畴。

  • “前端脱敏展示了” → 传输层仍是明文就会被抓到。

（5）快速自查清单（字段）

  • 抓包后能否一眼看到手机号/证件号/卡号原值？

  • 能否对负载跑正则、Luhn 并命中？

  • 有无把敏感信息放在 Header 或 URL（即便HTTPS，服务端/代理日志易泄）？

  • 是否使用 AEAD（AES-GCM/ChaCha20-Poly1305），是否携带 iv/tag？

  • 是否对请求做 签名/HMAC，包含 ts/nonce 抗重放？

2、HTTP 而非HTTPS ⇒明文传输

（1）检测人员如何确认

  • 看请求行/抓包条目：http://（非TLS）一目了然。

  • 扫描域名是否开启HSTS、是否支持 TLS1.2/1.3、证书是否有效/可信。

  • 检查是否存在HTTP→HTTPS 302 跳转（首次请求仍是明文暴露）。

（2）为什么“HTTP=明文”

  • 无TLS：请求方法、URL、Header、Body、Cookie 全部裸奔，任何中间链路均可读取/篡改。

  • 常见风险：会话劫持（Cookie被窃）、隐私信息被动采集、响应注入（JS/广告/恶意内容）。

（3）即便用了HTTPS，仍需注意的边界与坑

  • 首跳明文：若用户访问 http://，再302 到 https://，第一次请求已明文。解决方法：强制全站HTTPS、开启 HSTS（含preload），小程序端只配HTTPS 域名。

  • TLS终止：CDN/网关处终止TLS，回源若用HTTP，就形成内网明文段。解决方法：边缘→源站也走TLS，必要时做 mTLS（双向认证）。

  • 日志与监控：即便HTTPS，服务器/网关日志会记录 完整URL/Headers/部分Body。解决方法：不要把敏感数据放在URL/Headers；严格日志脱敏与留存策略。

  • 证书被动信任检查：审计常装“企业根证书”以解密流量；如你要求 证书绑定/域名固定（pinning），则他们无法MITM 解密，但这不影响他们判定你是否用了HTTPS。

  • 混合内容/第三方HTTP 资源：主请求是HTTPS，但上报/图片/埋点误用HTTP → 一样判定存在明文链路。

（4）正确姿势（传输层）

  • 只允许HTTPS（TLS1.2+），全域名在小程序后台白名单中均为HTTPS。

  • 开启HSTS（含preload），后端/微服务之间亦使用 TLS，最好 mTLS。

  • 设定强密码套件、关闭弱算法，启用 Perfect Forward Secrecy。

  • Referrer-Policy 设为 no-referrer 或 strict-origin-when-cross-origin，防止URL 泄露到第三方。

  • 严禁在URL/Headers 放PII，避免被各类日志系统“顺手带走”。

（5）快速自查清单（传输）

  • 是否存在任何 http:// 请求（含埋点/图片/第三方SDK）？

  • 首次访问是否可能发生 http → https 跳转？是否启用 HSTS preload？

  • CDN/网关到源站是否仍是 HTTPS？是否启用 mTLS？

  • TLS 版本/套件是否符合基线（TLS1.2/1.3，禁用弱套件）？

  • 是否设置 Referrer-Policy，并避免URL/Header 携带PII？

声明：本文来自数据合规与治理，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。