小程序渗透测试，小程序渗说白了就是透测跟微信抢时间。

我见过太多团队把小程序当App测，小程序渗一上来就抓包、透测扫目录、小程序渗测SQL注入。透测方向没错，小程序渗但忽略了一个致命前提：小程序的透测核心代码早就被打包下载到用户手机里了。你不需要费劲去黑服务器，小程序渗直接反编译那个.wxapkg文件，透测就能把前端逻辑扒个底朝天。小程序渗

有一次我测试某电商小程序，透测登录接口做了sign签名校验，小程序渗服务端验签很严格。透测常规思路是小程序渗逆向JS找加密函数，但那代码混淆得跟天书似的。我换了个路子——直接看小程序的本地缓存。结果发现用户点击“领取优惠券”时，前端会把一个`couponStatus`字段写到storage里，值为`claimed`。我手动改成`unclaimed`再重新触发请求，服务端居然直接发了张新券。这哪是渗透测试，这是帮商家做促销。

这类问题根源在于，开发者默认前端存储不可信，但小程序生态里很多人图省事，把业务判断全压在前端。

再聊个更隐蔽的点：小程序和App不同，它的网络请求默认走微信的代理，但很多测试工具抓不到。你得在微信里手动设置代理，或者用Proxifier强制转发。这还不算完，小程序有时会校验证书，你得上JustTrustMe这类模块绕过SSL Pinning。有一次我卡在这步整整两小时，最后发现是微信7.0.8版本以后默认开启了“仅信任系统证书”，得把Burp的CA装进系统证书目录才行。这种坑，文档里不会写，全靠试。

代码审计也别只盯接口。小程序有个`wx.navigateToMiniProgram`的API，允许跳转到别的开发者的小程序。如果目标小程序没做来源校验，你就能构造恶意跳转，诱导用户进入仿冒页面钓鱼。我测过某金融类小程序，它跳转合作方时只校验了`extraData`的签名，但没校验`appId`是否在白名单内。伪造一个同名appId，就能让用户跳到我的假登录页收集账号密码。这招比直接拖库狠多了。

不过话说回来，现在微信的风控越来越严。你频繁调用敏感接口，或者短时间内大量注册测试账号，微信后台会直接封禁你的微信号，连带着目标小程序一起遭殃。所以测试前最好准备几个新号，操作节奏放缓，别像扫漏洞那样狂轰滥炸。

最后提个反直觉的观察：小程序的后端往往比App后端更脆弱。因为开发周期短，很多团队直接用云开发，数据库权限配置稍微疏忽，就能通过`wx.cloud.database()`直接读取其他用户的记录。我曾在某论坛小程序里，用一条`db.collection('users').where({ _openid: '别人的openid'}).get()`就把用户手机号拉出来了。云开发默认的安全规则只校验登录态，不校验数据归属，这个坑踩中的人极多。

小程序是个杂交体，前端像网页，运行环境像App，后端又常常是云函数。测试时别套用任何单一方法论，得顺着业务逻辑摸清数据流，尤其盯着那些“前端信任边界”和“云开发默认配置”。每多测出一个这类漏洞，就少一个被薅羊毛的商家。当然，前提是你得先熬过抓包那关。