打开一个App，洞扫输入手机号，洞扫点“获取验证码”，洞扫抓包，洞扫把返回包里的洞扫code字段从{ "code":500}改成{ "code":200}——短信验证码那关就过了。这不是洞扫什么高深攻击，一个刚学会Burp Suite的洞扫实习生十分钟就能搞定。我见过太多团队把安全测试留到上线前三天，洞扫结果扫出一堆“用户名枚举”“短信轰炸”“越权查看订单”这类低级问题，洞扫修都来不及修。洞扫

漏洞扫描工具本身不神秘。洞扫MobSF拖个APK进去，洞扫它自动反编译、洞扫看Manifest、洞扫跑静态规则，洞扫几分钟吐一份报告。但工具报出来的东西，一半是误报，一半是它看不懂的业务逻辑漏洞。比如它告诉你android:exported="true"，可这个Activity本来就该被外部调用，你改回false反而破坏功能。真正要命的是那些工具扫不出来的：修改userId参数就能看别人订单，接口返回了不该返回的idCard字段，或者/api/v1/user/delete这种接口居然没做权限校验。

抓包改包才是重头戏

静态扫描只能覆盖三成问题。剩下七成得靠动态测试——说白了就是抓包、改包、重放。用Charles或Fiddler挂上代理，把App的流量全过一遍。登录接口把password字段删掉试试，看服务端会不会报空指针；订单查询接口把pageSize改成10000，看它限不限制；支付回调接口把amount从1改成0.01，看它验不验签。这些操作不需要什么黑客技术，一个懂HTTP协议的后端开发自己就能测。

去年有个电商App的案例我印象很深。测试人员发现“申请退款”接口只校验了订单号，没校验订单归属。用A账号登录，把B账号的订单号填进去，退款直接打到A的账户。这个漏洞在静态扫描报告里一个字都没提，因为代码逻辑本身“合法”——它只是忘了查userId。工具能告诉你哪里有SQL拼接、哪里用了MD5，但它不知道“这个接口应该只允许本人操作”。

几个高频翻车点

短信接口不设频率限制，一个手机号能发几百条，运营商账单来了才发现。用户信息接口返回全量字段，包括身份证、银行卡、密码哈希，前端虽然不显示，但抓包全看得到。WebView里setJavaScriptEnabled(true)加上addJavascriptInterface，在Android 4.2以下就是远程代码执行。还有硬编码在strings.xml里的API密钥，反编译出来直接能用。这些问题的共同点是：开发觉得“没人会这么干”，但攻击者恰恰就这么干。

扫描频率也有讲究。新版本发版前跑一次全量，日常每周跑一次增量。别指望扫完就万事大吉，很多漏洞是业务迭代带出来的——新加一个“分享得优惠券”功能，可能就引入了CSRF；改一下用户中心接口，可能就把idCard字段暴露了。把扫描集成到CI里，每次合并代码自动跑一遍，比上线前突击强得多。

修漏洞比扫漏洞难

扫出200个问题，开发说“排期紧，下个版本修”，然后下个版本又加新功能。真正有效的做法是分级：P0的越权、注入、敏感信息泄露，必须当版本修；P1的日志打印、Activity导出，可以排期；P2的Debug标志、备份允许，看情况。别把工具报告直接甩给开发，他们看不懂CWE-798是什么意思。把漏洞翻译成“这个接口不登录也能调，能查到所有用户手机号”，他们立刻就知道严重性了。

最后说个实在的：没有哪个App是“扫完就安全”的。漏洞扫描只是底线检查，真正扛得住攻击的团队，是把安全当代码规范来写——每个接口默认加权限注解，每个返回对象默认做字段过滤，每次git push前跑一遍semgrep。工具能帮你找问题，但修问题的永远是人。