APP小程序源码敏感信息扫描实战：从正则规则到自动化闭环

1. 为什么要专门扫描 APP 和小程序的源码

1.1 前端代码是“半公开”的敏感信息重灾区

做云上安全检查这几年，我几乎每次都要把一个动作放在最靠前的位置：把目标项目的APP安装包、小程序源码包拉下来，喂给一个敏感信息递归扫描器。先说明白，这不是多疑，而是“前端代码里藏密钥”的命中率高得惊人。有一回在某客户的小程序包里，光AccessKey就扫出来十多条，其中两条还能直接关联到云上的存储服务；另一次在APP解压后的JS bundle里发现硬编码的JWT令牌，拿着这个令牌就能调后端用户信息接口。因为前端代码本质上属于“半公开资产”，只要包能下载、能解包，里面所有字符串都等于裸奔。

很多开发团队会有个误解：密钥只要不放在后端仓库，放进前端代码就没事。实际上APP、小程序这类客户端包都要下发到用户设备上，APK解压后可以看到assets、res目录，小程序包解包后能看到JS、WXML、WXSS文件，React Native的bundle文件更是整段明文JavaScript躺在里面。如果你把云厂商的AK写在某个API请求封装里，把JWT直接塞进本地存储初始化代码里，那这条密钥就相当于印在名片上发给了所有使用者。并不是开发者刻意作死，而是本地调试时图省事，或测试环境变量写死之后忘了拆，这种事每天都在发生。

除了直接写出密钥，还有一种常见情况是“间接泄露”：代码里保留了一个完整的调试接口地址，带上某个固定Token就能访问内网数据。这种Token没有明显前缀，单靠正则不好抓，所以在扫描时除了匹配密钥本身，还要把可疑的“上下文片段”都捞出来给人工复核。这也是我为什么一直坚持自己维护一套扫描脚本，而不是完全依赖现成工具的最大原因：真正的敏感信息，很多时候不是一眼就能认出来的标准格式。

1.2 扫描范围怎么定：不是所有目录都要扫

再说一个容易被新手忽略的环节：扫描范围。第一次用这套脚本的人总想着把整个解包目录一锅端，结果扫出来上万条“疑似手机号”，其中大半是订单号、随机数字串，根本没法看。我自己现在会按目标类型把范围收紧。

小程序场景下，重点扫解包后的主包、分包目录，以及云函数代码目录（如果存在泄漏的话）。APP场景下，重点扫APK或IPA解压后的根目录，尤其是assets、res/raw、js、bundle等目录；Flutter、RN这类跨端项目的JS bundle通常体积很大，但里面往往藏着完整的业务逻辑和请求配置。配置文件类我单独划了一圈优先级，包括.json、.properties、.env、.yml、.yaml、.php、.java、.js、.ts这类文本文件。

同时必须明确哪些目录要跳过。最典型的是node_modules、.git、miniprogram_npm这些目录。第三方依赖包里的代码不是你写的，扫出来的命中结果几乎全是噪音；.git目录内部是压缩对象和二进制索引，既不适合文本匹配，又会拖慢速度。我在脚本里保留了一个SKIP_DIRS黑名单，遍历时直接剪枝。这一步不是嫌麻烦，而是为了让结果聚焦在“自己人写的前端代码”上，减少人工复核的负担。

注意：扫描不是越全越好，先把目录范围定清楚，否则后面的报告会变成一场灾难。

为什么强调“递归多层目录”？因为真实解包后的目录深度比大多数人想象中夸张。一个APK解压后，常见路径类似assets/rn/bundles/com/xxx/module/src/index.android.bundle，层级轻松超过六层；小程序分包解压后也有大量嵌套。手工打开文件夹一层层翻，或者用编辑器逐个搜索，效率极低还不忘漏。递归目录遍历的能力，本质上是扫描器的地基，地基不稳，后面所有规则都白搭。

2. 敏感信息类型与检测规则的设计思路

2.1 五类核心敏感信息与正则规则表

规则设计是整个扫描器最有含金量的地方。我不能直接把一堆正则堆给你，因为如果规则过于宽松，扫描结果等于废纸。先看我目前在用的五类核心规则表：

先说云厂商AK。各家AK格式虽然不同，但都有比较明显的前缀和长度约束，例如LTAI后面跟一串字母数字，AKIA后面跟16位大写字母和数字，AKID后面跟一长串字符。正则里用(?i)打开不区分大小写，再用前后边界断言(?<![a-z0-9])和(?![a-z0-9])卡死边界，防止它作为更长字符串的一部分被误匹配。这一招能直接过滤掉很多没用的命中。

JWT的正则设计核心是抓“三段式”。JWT的Header部分base64url解码后通常是{"alg":"HS256","typ":"JWT"}，开头固定是eyJ这串字符，整个Token结构是三段base64url字符，中间用点号分隔。所以正则写成eyJ[A-Za-z0-9_-]{5,}\.[A-Za-z0-9_-]{5,}\.[A-Za-z0-9_-]{5,}，比单纯匹配任意三段点号分隔字符串要稳得多。

手机号和身份证的情况有点特殊。手机号的格式本身很简单，1[3-9]开头加9位数字，但这条规则单独使用会误报爆炸。订单号、时间戳、随机数字串里只要出现11位数字，全都会被当成手机号捡出来。所以我把手机号命中分成两档：如果行上下文里出现了mobile、phone、phoneNumber、contact这类字段名，标为“中风险”；否则只作为“低危线索”记录，不进入主报告。身份证同理，正则部分先做基本格式校验，后面再讲可以加校验位二次确认。

2.2 降低误报的关键：前缀锚定与上下文加权

如果你只是写一个正则然后往文件里怼，那叫grep，不叫敏感信息扫描。真正有实用价值的检测规则，必须同时做三件事：前缀锚定、长度约束、上下文加权。

前缀锚定的意义和上面AK规则一样。比如身份证正则如果用\d{17}[\dXx]这种写法，任何17位数字加一个尾号都会被扫出来，乱码、哈希值、加密串全都会被误报。改成[1-9]\d{5}(?:19|20)\d{2}(?:0[1-9]|1[0-2])(?:0[1-9]|[12]\d|3[01])\d{3}[\dXx]之后，相当于把地区码、出生年份、月份、日期全部做了一遍格式校验，虽然还有理论上误报的可能，但概率大幅下降。如果再配上身份证校验位计算，基本可以滤掉绝大部分噪声。

上下文加权是更进一步的优化。因为很多时候密钥本身并没有固定的“云厂商前缀”或者“JWT三段式”结构，它就是一行appSecret = "K8mNpQ2X..."这样的随机串。这时候单靠正则根本不知道该不该报警。我的做法是维护一个关键词列表，包括secret、token、password、passwd、accessKey、access_key、apiKey、api_key等。当关键词命中了某一行，就提取该行等号右侧的连续字符串，用字符集约束（只包含大小写字母、数字、若干特殊符号）来判断它像不像一个密钥。

长期跑下来，我发现“上下文加权”比“堆更多正则”更有效。因为真实项目里的敏感信息形态太多了，你不可能为每一种云服务、每一种框架的配置格式都写一条规则。把上下文作为重要的辅助信号，能覆盖那些没有固定格式的泄密点。当然这也意味着结果里会有一些“可能敏感但不确定”的条目，需要人工扫一眼，但总比一条条去读几千行代码强。

3. 递归多层目录扫描与文件处理实现

3.1 目录遍历策略与循环目录避让

目录遍历我直接使用Python的os.walk，它本身就是递归实现，可以一层层往下走。关键参数是followlinks=False，这一点很容易被忽略。如果目标目录里有符号链接指向某个上级目录，而你又开启了跟随链接，遍历会陷入无限循环，最后把磁盘跑满。对于那些确实需要扫描链接目标的特殊场景，我会改用手动维护已访问目录集合的方式：每进入一个目录，先取os.path.realpath，把它放进一个Python集合，如果遇到已经在集合里的目录就跳过。

扫描过程中还要控制最大深度，防止某些自动化解包程序生成异常深的目录把文件系统功耗拉满。我的默认设置是允许30层深度，超过就停止递归。这个值对于正常项目完全够用，因为多数目录层级都不会超过10层，30层只是为了兜底一些极端嵌套的压缩包解压结果。

遍历规则里还有个很重要的细节：剪枝。在os.walk循环里直接处理dirnames列表，把SKIP_DIRS里的目录名过滤掉，例如node_modules、.git、.svn、miniprogram_npm等。这样做不只是为了减少误报，也能大幅提高扫描速度。我见过有人把node_modules目录整个扫一遍，几分钟都跑不完，因为里面全是几万个JS文件；实际上那些代码和自家业务没有任何关系。

3.2 文件白名单、编码判定与大文件保护

遍历到文件后，第一件事不是立即读内容，而是先做一轮“值得扫”判断。我会维护一个文本扩展名白名单，包括.js、.ts、.json、.html、.htm、.xml、.txt、.log、.md、.vue、.wxml、.wxss、.php、.py、.java、.properties、.yml等。白名单之外的文件，比如图片、字体、压缩包、二进制so库，直接跳过。

扩展名白名单是效率基础，但不是万无一失。有些配置文件没有扩展名，比如.env文件（实际名是.env，没有后缀）；还有些从服务器上下载的源码文件后缀混乱。所以我还会做二次探测：打开文件读取最前面2KB字节，如果里面包含\x00这种空字符，就判定为二进制文件并跳过。这套“扩展名+头字节探测”的组合，覆盖了我遇到的大部分文本文件场景，而且性能消耗很小。

编码处理是另一个容易翻车的点。很多老旧项目的配置文件是GBK编码，如果你强行用utf-8解码，轻则乱码，重则直接抛异常导致扫描中断。我现在的读取逻辑是按顺序尝试utf-8、gb18030两种编码，都用try/except UnicodeDecodeError包裹处理。如果都失败，最后用utf-8加errors='ignore'兜底。gb18030是GB2312和GBK的超集，能覆盖绝大多数中文编码场景，用这一个就够。

大文件保护也很关键。bundle文件动辄几十MB，如果你一次性read()进内存，小机器直接卡死。我的做法是把最大文本文件大小默认设置为20MB，超过就跳过；但某些RN或Flutter的bundle会超过这个门槛，所以我把大小阈值设计成可配置参数，遇到大项目时调高。避免一次把整个文件读入内存的另一个办法是流式逐行读取，但逐行读取会在正则匹配跨行上下文时受限，所以我在效率和覆盖之间默认选择阈值跳过，扫描结果里会明确标出“因文件过大未扫描”，避免误以为自己扫得很干净。

4. 核心扫描实现与报告输出

4.1 规则管线与命中去重

扫描核心的管线逻辑其实很清晰：遍历文件 -> 读取文本 -> 预编译正则逐条匹配 -> 命中后提取行号和上下文 -> 计算风险等级 -> 脱敏 -> 汇总结果。我贴一个精简版可直接运行的示例，核心参数都在里面，你自己可以根据项目情况调整。

import os import re import json from pathlib import Path TEXT_EXTS = {'.js', '.ts', '.json', '.html', '.htm', '.xml', '.txt', '.log', '.md', '.vue', '.wxml', '.wxss', '.php', '.py', '.java', '.properties', '.yml', '.yaml', '.env'} SKIP_DIRS = {'node_modules', '.git', '.svn', 'miniprogram_npm', '__pycache__'} MAX_FILE_SIZE = 20 * 1024 * 1024 MAX_DEPTH = 30 RULES = [ { "name": "cloud_access_key", "risk": "high", "regex": r"(?i)(?<![a-z0-9])(?:LTAI[a-z0-9]{12,20}|AKIA[0-9a-z]{16}|AKID[a-z0-9]{13,20})(?![a-z0-9])" }, { "name": "jwt_token", "risk": "high", "regex": r"eyJ[A-Za-z0-9_-]{5,}\.[A-Za-z0-9_-]{5,}\.[A-Za-z0-9_-]{5,}" }, { "name": "mobile_number", "risk": "medium", "regex": r"(?<![0-9])1[3-9]\d{9}(?![0-9])" }, { "name": "id_card", "risk": "high", "regex": r"(?<![0-9])[1-9]\d{5}(?:19|20)\d{2}(?:0[1-9]|1[0-2])(?:0[1-9]|[12]\d|3[01])\d{3}[\dXx](?![0-9])" }, { "name": "private_key_block", "risk": "high", "regex": r"-----BEGIN (?:RSA|EC|OPENSSH|DSA|PRIVATE) PRIVATE KEY-----" }, ] CONTEXT_KEYWORDS = ["secret", "token", "password", "passwd", "accesskey", "access_key", "apikey", "api_key"] def is_binary(raw: bytes) -> bool: return b'\x00' in raw[:2048] def load_text(path: Path): try: raw = path.read_bytes() except OSError: return None if len(raw) > MAX_FILE_SIZE or is_binary(raw): return None for enc in ("utf-8", "gb18030"): try: return raw.decode(enc) except UnicodeDecodeError: continue return raw.decode("utf-8", "ignore") def mask_phone(phone: str) -> str: return phone[:3] + "****" + phone[-4:] def mask_idcard(idcard: str) -> str: return idcard[:6] + "********" + idcard[-4:] def scan_text(path: Path, text: str): lines = text.splitlines() hits = [] for line_no, line in enumerate(lines, start=1): lower_line = line.lower() for rule in RULES: for match in re.finditer(rule["regex"], line): value = match.group(0) ctx_flag = 1 if any(k in lower_line for k in CONTEXT_KEYWORDS) else 0 risk = rule["risk"] if rule["name"] == "mobile_number" and ctx_flag == 0: risk = "low" if rule["name"] == "mobile_number": value = mask_phone(value) if rule["name"] == "id_card": value = mask_idcard(value) hits.append({ "pattern": rule["name"], "risk": risk, "file": str(path), "line": line_no, "match": value, "context": line.strip()[:200], }) return hits def main(root: str): root_path = Path(root) all_hits = [] files_scanned = 0 for dirpath, dirnames, filenames in os.walk(root_path, followlinks=False): dirnames[:] = [d for d in dirnames if d not in SKIP_DIRS] depth = Path(dirpath).relative_to(root_path).parts if dirpath != root_path else () if len(depth) > MAX_DEPTH: dirnames[:] = [] continue for filename in filenames: p = Path(dirpath) / filename if p.suffix.lower() not in TEXT_EXTS: continue text = load_text(p) if text is None: continue files_scanned += 1 all_hits.extend(scan_text(p, text)) summary = {} for h in all_hits: summary[h["pattern"]] = summary.get(h["pattern"], 0) + 1 report = { "scan_root": str(root_path), "files_scanned": files_scanned, "total_hits": len(all_hits), "summary": summary, "hits": all_hits, } return report if __name__ == "__main__": result = main("/path/to/your/source") print(json.dumps(result, ensure_ascii=False, indent=2))

这个脚本的规则表我刻意放在文件顶部，方便你增删。scan_text函数的核心是逐行匹配，每命中一个规则就把文件路径、行号、脱敏后的匹配值以及上下文片段记录下来。上下文片段非常重要，因为人工复核时不可能每次都重新打开源文件，报告里直接能看到“这段代码大概在做什么”。

命中去重我放在汇总阶段处理。同一个文件同一行可能被多条规则命中，例如一行配置里同时出现手机号和身份证号，那就应该记录两条，不能合并。同一行同一个正则连续出现多个匹配值，例如数组里列了十多个手机号，我按每个匹配值分别记录，但报告里会压缩上下文，避免一个数组就把报告撑爆。

4.2 成果输出：JSON 报告与统计摘要

输出格式我选JSON，不用CSV。原因很简单：JSON能嵌套展示上下文、文件路径、行号、风险等级这些结构化字段，后续接入告警平台、导入其他工具都很方便。CSV虽然能用Excel打开，但字段一多就是灾难，尤其上下文里可能包含逗号和换行，会让表格乱掉。

报告里必须带上统计摘要，也就是每个规则命中多少次。不要小看这个汇总，它能直接告诉你这个项目最严重的问题是什么。如果一个包扫出50条JWT令牌但AK只有1条，说明这个团队的鉴权体系可能整体都暴露了，而不只是某个配置文件写错。如果手机号命中数极高但高优命中很少，说明这套代码里有大量个人信息在流转，本身就值得警惕。

我对不同风险等级的处理策略是：高优命中（AK、私钥、JWT、身份证）立刻拉群通知负责人；中、低风险放进周报汇总。报告落地后，手机号和身份证必须保持脱敏状态。这一点非常重要，因为报告本身可能被转发、归档，如果里面躺着一批明文身份证号，那扫描器反而成了新的数据泄露源头。

5. 实操中的高发问题与排查记录

5.1 五个容易“翻车”的场景

这套方案跑了两年多，我遇到过的问题基本可以浓缩成一张速查表：

先展开说下JWT误报。base64编码的任意图片、密文、序列化数据，如果开头两个字符刚好是eyJ，又恰好被点号分成三段，就会被当JWT扫出来。我自己遇到过一个案例，一个配置文件里藏了一长串base64编码的加密数据，扫描器报了JWT，人工复核时才发现完全不是。降低误报的方法是在命中后再写一个校验函数，把第一段尝试用base64url解码，看解码结果是不是以{开头且包含alg字段。这个校验逻辑不复杂，但能把误报率降低一个数量级。

手机号误报是我日常最头疼的问题。前端代码里的订单号、流水号、假手机号测试用例非常多。我的处理方式是分档：匹配到手机号后，如果单行上下文里有mobile、phone、contact、phoneNumber这类字段名，就标记为“中风险”；没有这些关键词时，仅作为“低危线索”进入附录清单，不进主报告。这样既不会漏掉真正的个人信息，又不会让主要结论淹没在噪声里。

5.2 性能优化手段

扫描器最大的性能瓶颈在于大目录里的海量文件遍历和文本读取。我有几个常用的提速手段。一是多进程。Python的concurrent.futures.ProcessPoolExecutor可以按目录或按文件列表分片并行处理，在多核机器上速度能提升三到五倍。要注意的是，多进程模式下每个子进程各自维护正则预编译结果，所以正则对象尽量做到模块级复用，避免反复编译。

二是先过滤后读取。前面讲的扩展名白名单和二进制头探测，能挡掉大部分无意义文件。很多APK解压目录里图片、音频、字体文件占了大多数，这些连打开都不需要，直接跳过。三是命中后的二次确认。对AK这类规则，可以再做一次前缀细分，把命中结果按厂商分组，方便报告按优先级呈现。如果扫描对象是固定的一批定期任务，还可以把扫描过的文件哈希存下来，内容没变就直接跳过，做成增量扫描。

特别提醒：报告里所有手机号、身份证展示必须脱敏，报告本身也可能被再次传阅，不能把扫描器变成新的泄露源。

6. 扫描结果如何落地：从发现到验证再到闭环

6.1 命中结果的人工复核与风险确认

扫描器给你一份命中列表，这只是开始。真正的工作量在于人工复核。我自己的复核流程是这样：看上下文片段，确认这个密钥是不是真实业务代码里正在使用的，而不是测试用例、历史遗留注释或示例代码。如果上下文里有硬编码的AK，下一步不是复制它去调什么接口，而是立刻确认供应商控制台里有没有异常操作，然后走正常流程轮换该密钥。

密钥轮换这个动作千万别省。有人发现前端代码里藏着AK，以为把代码删掉重新发布就完事了。但旧包可能已经在线上保留了一段时期，或者被其他渠道下载过，删除源码只是阻止了进一步扩散，已经暴露的密钥依然可以继续使用。正确的做法是到云控制台禁用、删除或轮换这把AK，再处理代码本身。这条补丁逻辑适用于所有高优命中，JWT要换签发密钥，数据库连接串要改密码，手机号身份证要评估是否涉及合规上报。

对于中低风险命中也不能直接无视。手机号这类个人信息的暴露意义不在“能不能用来登录”，而在于这本身就是合规问题。如果前端代码里存在一批明文手机号和身份证号，通常意味着某个接口、某个文件、某个日志在某个环节上把个人信息落到了不该落的地方。顺着命中的上下文继续追踪，往往会发现更深的问题，比如某个调试接口未鉴权、某个日志文件被直接打包进了安装包。

6.2 把扫描器接进日常版本的发布流程

扫描器最合适的定位不是“出事之后再跑”，而是“发布之前就拦”。把扫描逻辑做成独立的命令行工具后，可以接进CI流水线。常见做法是在前端构建完成、生成安装包或小程序产物后，自动对产物目录执行一次扫描。如果出现高优命中，构建失败或触发告警；中低风险问题则允许构建通过，但自动把报告发给相关负责人。

我见过一些团队直接拿扫描失败卡住发布流程，结果因为规则误报让正常上线被阻断，开发同学抱怨不断。所以我的建议是区分“阻断项”和“提示项”。AK、私钥、JWT这类高优命中建议阻断；手机号、身份证这类需要结合上下文的规则先走提示，不要一刀切。等规则库稳定了，再把误报率降到足够低的常见模式提升为阻断项。扫描结果接上企业内部的IM告警群、工单系统，才算真正形成闭环。

最后说一点非常碎但很实在的经验：敏感信息扫描这件事，最忌讳“扫完发完报告就结束”。我见过有团队用脚本扫出了几十条AK，发了一份漂亮的报告，然后就没有然后了。几个月后再看，那些密钥原样躺在线上包里，风险一点没减少。我自己现在维护的这套扫描器，每个月固定跑一遍全部线上小程序包和APP包，发现新增命中就盯到负责人完成密钥轮换。扫描是一种习惯，不是一次性任务。与其追求一个完美无瑕的规则库，不如先把“定期扫描+人工复核+强制闭环”这套节奏跑起来。