客户端app特有的个漏漏洞类型，掰着指头数，洞类真正“只”出现在客户端的型只现客其实不多。但有一个，出户端几乎算得上是个漏客户端的“专属烙印”——不安全的本地存储。别的洞类漏洞，比如SQL注入、型只现客SSRF，出户端服务端也有，个漏甚至更严重。洞类可本地存储这问题，型只现客天然长在客户端这片土壤上，出户端服务器端压根没这概念。个漏

你可能会说，洞类Web端不也有localStorage吗？型只现客对，但区别在于：Web的localStorage是浏览器沙箱里的一个临时抽屉，页面一关，权限就回收了。而移动app的本地存储，是直接躺在用户手机文件系统里的真实文件——SharedPreferences、SQLite数据库、或者干脆一个plist。这些文件，app自己怎么读写，攻击者就能怎么读写。更扎心的是，很多app把不该放的东西往这儿塞。

举个我亲眼见过的例子。某款记账app，把用户PIN码做了个简单的哈希，然后存在了SharedPreferences里。哈希算法不是重点，重点是，攻击者拿到root权限的手机，直接读那个xml文件，拿到哈希值，离线暴力破解。四位数PIN，几秒钟的事。这还不算完，更蠢的是有些app把JWT令牌、session key直接明文写在本地文件里。手机一旦被植入恶意软件，或者用户自己越狱/root了，那这些凭据就是拱手送人。

有人会杠：那Web端不也能通过XSS偷localStorage吗？确实能，但前提是得先打穿XSS。而客户端本地存储的暴露，根本不需要任何远程漏洞——你只需要物理接触那台手机，或者诱导用户装个恶意app。攻击面完全不一样。服务端漏洞得隔着网络打，本地存储漏洞是直接在“犯罪现场”捡证据。

另一个被忽视的点是备份与同步机制。iOS的iTunes备份，Android的ADB备份，都会把app的沙盒数据原封不动打包出来。哪怕app自己没漏洞，只要它把敏感信息写进本地存储，就等于在备份文件里埋了雷。我见过一个企业IM工具，把聊天记录里的图片缓存直接明文存在Documents目录，结果用户手机连电脑备份，整个聊天内容裸奔在硬盘上。这漏洞类型，Web端想复现都难——浏览器没有“整机备份”这回事。

当然，你得区分“本地存储”和“内存存储”。内存里变量泄露那是另一码事，而且生命周期短。本地存储的特点是持久化，攻击者随时可以来取。所以判断一个漏洞是不是客户端独有，就看它是否依赖“设备本地的持久化介质”作为攻击前提。服务端代码再烂，也碰不到用户手机里的文件——除非它主动上传，但那就变成数据泄露了，不是本地存储漏洞。

最后说个反直觉的观察：很多开发者觉得，把数据加密后再存本地就安全了。但加密密钥放哪？还是得放本地。这就陷入了一个死循环——你保护数据的钥匙，和锁放在同一个抽屉里。真正的解法是压根别把高价值数据落盘，或者用系统级Keystore做硬件隔离。可惜，现实里大部分app都图省事，直接明文或弱加密写入。这个漏洞类型，从2010年移动互联网爆发到今天，依然在OWASP Mobile Top 10里稳居前排，说明人类对“方便”的追求，永远比对“安全”的追求更执着。

所以，下次做安全测试，先别急着扫服务端接口。打开app的沙盒目录翻一翻，可能比黑盒打一天漏洞收获还大。