移动端Web接口扫描：Fiddler与Nuclei联动实战指南

1. 为什么移动端Web接口扫描不能只靠“抓包看一眼”

你有没有遇到过这样的场景：App里点一个按钮，界面上弹出个“网络错误”，开发说“后端接口挂了”，测试说“我抓包没看到请求发出”，安全同事翻着Fiddler的会话列表说“这接口参数明显没校验，但怎么复现不了？”——三个人围着同一台手机，各自看到的却是三个平行宇宙。这不是玄学，是典型的移动端Web接口扫描断层现象：抓包工具能看到流量，但看不到业务逻辑；自动化扫描器能跑出一堆SQLi告警，但90%是误报，因为根本没理解这个接口是登录态续期还是图片上传；而App本身又像黑盒，你不知道它什么时候发请求、带什么Header、加密参数怎么生成。

这就是本篇标题里“联动”的真实含义——不是把Fiddler和Burp塞进同一个窗口，而是让流量捕获、上下文理解、漏洞验证三者形成闭环。关键词里的“移动端Web接口”，特指那些嵌在App里的WebView、Hybrid页面、小程序内嵌H5，它们共享App的Cookie、Token、自定义Header，甚至调用Native桥接方法生成动态参数。这类接口的扫描，和纯浏览器访问的Web站点有本质区别：证书校验绕过方式不同、HTTPS中间人配置更复杂、请求链路可能被App层拦截重写、响应数据常带Base64或AES密文。我试过直接把PC端跑通的Burp插件丢进手机代理，结果连首页都打不开——不是插件不行，是它压根没处理Android 7+系统对用户证书的默认拒绝策略。

所以这篇教程不讲“怎么装Charles”，也不教“Burp怎么配Proxy”，而是聚焦一个具体动作：当你在Fiddler里看到一条/api/v2/user/profile?token=xxx的GET请求时，如何在3分钟内判断它是否可被未授权访问、参数是否可篡改、响应是否泄露敏感字段，并自动生成可复现的PoC脚本。适合两类人：一是做移动App渗透的白帽子，手上有测试机但缺系统化流程；二是开发自测阶段的安全工程师，想在上线前快速筛出高危接口。接下来所有步骤，我都基于真实项目复盘——某金融类App的H5钱包页，我们用这套联动方案，在两天内定位到3个越权读取他人账户余额的接口，其中1个连基础的身份校验都没做。

2. Fiddler/Charles不是万能钥匙：移动端抓包的三大隐性门槛

很多人以为装好Fiddler、手机配好代理、证书导入成功，就能“所见即所得”地看到所有接口。实测下来，至少70%的移动端Web流量会在这一步卡住。问题不在工具本身，而在移动端特有的网络栈设计。下面拆解三个最常被忽略的隐性门槛，每个都附带可立即验证的排查命令和修复方案。

2.1 HTTPS证书信任链断裂：Android 7+与iOS 10.3+的“静默拦截”

Fiddler和Charles生成的根证书，在旧版Android（6.0以下）和iOS（10.2以下）上导入后基本能用。但新系统做了两件事：一是Android 7开始默认不信任用户安装的CA证书，除非App在network_security_config.xml里显式声明；二是iOS 10.3后要求手动点击“信任”证书，且需在“设置→已下载描述文件”里二次确认。更麻烦的是，很多金融、政务类App会主动检测代理环境，一旦发现SSL证书非系统预置，直接终止WebView加载。

提示：不要依赖“手机浏览器能打开Fiddler官网”来判断代理是否生效。WebView使用的TrustManager和系统浏览器完全不同。

验证方法很简单：在手机终端执行

curl -v https://httpbin.org/get --proxy http://你的电脑IP:8888

如果返回SSL certificate problem: unable to get local issuer certificate，说明证书未被信任；如果返回Connection refused，说明代理根本没通。前者要进手机设置手动开启证书信任（Android路径：设置→安全→加密与凭据→信任的凭据→用户；iOS路径：设置→通用→关于本机→证书信任设置），后者需检查防火墙是否放行8888端口、手机Wi-Fi DNS是否被强制指向运营商地址。

但即使证书信任了，App仍可能不走代理。这时需要强制App使用代理——对Android调试版APK，可用adb shell settings put global http_proxy 192.168.1.100:8888；对iOS则需借助Network Link Conditioner模拟弱网，触发App降级使用HTTP协议（部分老版本SDK会这样）。我踩过的最大坑是：某银行App在Wi-Fi下走直连，切到4G才走代理，因为它的网络检测逻辑里写了if (wifi) use direct; else use proxy。

2.2 WebView的自定义网络栈：OkHttp与WebViewClient的双重过滤

现代App几乎不用原生WebView，而是集成OkHttp（Android）或NSURLSession（iOS）作为网络层，再通过WebViewClient.shouldInterceptRequest()或WKNavigationDelegate.decidePolicyFor拦截请求。这意味着：Fiddler/Charles只能捕获到“经过系统网络栈”的流量，而OkHttp自己构建的Request（比如上传头像用的MultipartBody）可能完全绕过系统代理。

验证方法：在Fiddler中开启“Decrypt HTTPS traffic”，然后在App里触发一个明确的网络操作（如刷新用户资料页），观察Fiddler会话列表。如果看到大量CONNECT请求但没有后续的GET/POST，说明流量被App层拦截了。此时需用Android Studio的Profiler或Xcode的Network Instrument抓底层Socket连接，对比Fiddler日志——漏掉的那几条，就是OkHttp直连的。

解决方案分两步：一是让OkHttp走系统代理，需在代码中添加new OkHttpClient.Builder().proxy(Proxy.NO_PROXY)并手动设置proxy为Fiddler地址；二是对WebView，重写shouldInterceptRequest()，把Request对象转成标准URL再交给OkHttp处理。但这需要源码权限。没有源码时，我的经验是：用Frida HookOkHttpClient.newCall()，把Request URL打印出来，再手动补到Fiddler的“AutoResponder”里模拟响应。虽然麻烦，但比盲扫高效得多。

2.3 动态Header与Token注入：App层埋点与风控系统的干扰

Fiddler看到的Authorization: Bearer xxx，很可能不是登录接口返回的原始Token，而是App在发送前拼接了设备指纹、时间戳、签名后的结果。比如某电商App的Header长这样：
X-Auth: SHA256(device_id+timestamp+token+secret_key)
你复制这个Header去Postman重放，100%失败，因为timestamp是毫秒级且有时效性。

更隐蔽的是风控系统插入的Header：X-Risk-Id: rsk_abc123、X-Session-Key: sess_xyz789。这些字段在Fiddler里可见，但来源不明——可能是Native层调用getRiskInfo()后注入，也可能是JSBridge从WebView里读取的localStorage值。

破解方法不是猜算法，而是定位注入点。在Fiddler中右键目标请求→“Edit in Notepad”，把整个Request保存为.txt。然后用grep -n "X-Auth\|X-Risk" request.txt定位字段行号，再结合App的JS Bundle（用apktool d app.apk解包后搜索X-Auth）找到生成逻辑。我处理过一个案例：X-Risk-Id实际是调用window.webkit.messageHandlers.risk.postMessage({})后，Native返回的JSON字符串，里面包含一个base64编码的risk token。这时候，自动化扫描器必须先调用这个JSBridge，再提取token拼到Header里，否则所有扫描都是无效的。

3. 扫描器不是“开箱即用”：选型、改造与上下文注入的关键逻辑

市面上的自动化扫描器（Burp Suite、Arachni、Nuclei）默认设计是针对传统Web服务器，对移动端Web接口存在三个硬伤：一是无法理解App特有的认证上下文（如双Token机制：access_token用于API，device_token用于风控）；二是对动态参数（如时间戳、随机数、签名）缺乏建模能力；三是无法处理WebView特有的响应解析（如<script>parent.postMessage(...)</script>这种跨域通信格式）。直接拿Burp的Intruder跑一遍，结果往往是：1000个请求里，990个因签名失效返回401，剩下10个因参数格式错误返回400，真正有效的漏洞一个没扫出来。

3.1 为什么放弃Burp Pro，选择Nuclei+自定义模板的组合

Burp Pro的Active Scan确实强大，但它把“扫描”和“代理”强耦合——你得先把目标加到Target scope，再手动发起Scan。而移动端场景下，你根本不知道哪些URL该加scope：Fiddler里一闪而过的/api/v3/track?event=page_view&ts=1712345678901，是埋点接口，扫它毫无意义；但/api/v2/transfer?to_account=xxx&amount=1000，就是高危转账接口，必须重点覆盖。

Nuclei的优势在于“协议无关”和“模板驱动”。它不关心你是HTTP还是WebSocket，只要提供URL列表，就能按模板规则逐条匹配。更重要的是，Nuclei的模板语法支持Go函数调用，可以实时计算签名、生成时间戳。比如这个模板片段：

requests: - method: GET path: - "{{BaseURL}}/api/v2/user/profile?uid={{rand_int(1000,9999)}}&t={{timestamp_unix}}&s={{sha256(concat('uid=', rand_int(1000,9999), '&t=', timestamp_unix, '&key=', 'abc123'))}}" headers: Authorization: "Bearer {{token}}" X-Device-ID: "{{rand_text(16)}}"

其中{{timestamp_unix}}、{{sha256(...)}}都是Nuclei内置函数，无需写Python脚本。而Burp的Intruder需要你提前生成好所有参数组合，存成payload文件，再导入——面对每秒生成新签名的接口，这根本不现实。

当然，Nuclei也有短板：它不维护会话状态，无法自动处理登录跳转。所以我们的方案是：Fiddler负责维持完整会话（登录态、Cookie、Token刷新），Nuclei只负责对Fiddler导出的“干净URL列表”做单点爆破。具体流程是：Fiddler抓到登录成功的请求→提取Set-Cookie和Authorization Header→用这些Header构造一个“基础请求模板”→导出所有/api/**路径到urls.txt→Nuclei用-l urls.txt -t templates/mobile/批量扫描。这样既利用了Fiddler的会话管理能力，又发挥了Nuclei的动态参数生成优势。

3.2 改造扫描器的核心：把Fiddler的“上下文”注入到扫描器

所谓“上下文”，不是简单复制Header，而是理解App的业务状态机。比如一个外卖App，用户必须先/api/v1/login，再/api/v1/address/list，最后才能/api/v1/order/create。如果扫描器直接扫/order/create，服务端会返回{"code":403,"msg":"address not set"}，这不是漏洞，是业务约束。

我的做法是：在Fiddler中编写CustomRules.js，监听特定响应，自动提取关键状态。例如，当Fiddler捕获到/api/v1/address/list返回200时，解析响应体中的default_address_id，存入全局变量：

if (oSession.uriContains("/api/v1/address/list") && oSession.responseCode == 200) { var body = oSession.GetResponseBodyAsString(); var json = JSON.parse(body); if (json.data && json.data.length > 0) { FiddlerObject.StatusText = "Default address ID: " + json.data[0].id; // 存入Fiddler的Memory list，供后续请求调用 FiddlerApplication.Prefs.SetStringPref("mobile.default_addr_id", json.data[0].id); } }

然后在Nuclei模板里，用{{.FiddlerPrefs.mobile.default_addr_id}}引用这个值。这样扫/order/create时，参数里自动带上真实的地址ID，而不是瞎填的12345。同理，对需要登录态的接口，Fiddler在每次收到/api/v1/login成功响应后，自动更新AuthorizationHeader的值，避免Token过期导致扫描中断。

注意：Fiddler的CustomRules.js修改后需重启Fiddler才能生效，且不能有语法错误，否则整个代理会挂掉。建议用VS Code配合FiddlerScript插件写，实时语法检查。

3.3 模板编写实战：从“看到接口”到“验证漏洞”的三步转化

以一个真实案例说明：Fiddler抓到GET /api/v2/user/info?uid=1001，响应是{"name":"张三","phone":"138****1234","email":"zhang@xxx.com"}。表面看是正常查询，但我们需要验证三点：1）uid参数是否可枚举（越权）；2）响应是否泄露脱敏不足的手机号；3）是否支持POST方式绕过GET限制。

对应Nuclei模板这样写：

id: mobile-user-info-leak info: name: Mobile User Info Endpoint Leakage author: security-team severity: high requests: # 步骤1：枚举uid，验证水平越权 - method: GET path: - "{{BaseURL}}/api/v2/user/info?uid={{rand_int(1000,1010)}}" matchers: - type: word words: - '"phone":"1' - '"email":"' condition: and extractors: - type: regex name: phone part: body regex: - '"phone":"([^"]+)"' # 步骤2：用POST方式重放，验证方法绕过 - method: POST path: - "{{BaseURL}}/api/v2/user/info" body: "uid={{rand_int(1000,1010)}}" headers: Content-Type: application/x-www-form-urlencoded matchers: - type: status status: - 200 # 步骤3：检查响应中手机号是否脱敏（正则匹配未脱敏格式） - method: GET path: - "{{BaseURL}}/api/v2/user/info?uid=1001" matchers: - type: regex regex: - '"phone":"1[3-9]\\d{9}"' # 匹配11位完整手机号

这个模板的关键在于：它不假设“uid=1001是当前用户”，而是主动枚举相邻UID（1000~1010），因为真实越权往往发生在相邻用户ID之间（数据库自增主键）。同时，用POST重放是为了测试服务端是否只校验了HTTP Method，而忽略了业务逻辑校验。最后的正则匹配，直接定位到脱敏缺陷——很多App前端做脱敏（显示138****1234），但后端返回的仍是明文，这是典型的“前端脱敏陷阱”。

4. 联动工作流：从Fiddler捕获到漏洞报告的完整闭环

前面讲了工具选型和原理，现在进入实操核心：如何把Fiddler、Nuclei、人工分析串成一条流水线，确保每个环节的输出都是下一个环节的精准输入。这不是简单的“先抓包再扫描”，而是建立一套可复现、可审计、可沉淀的标准化流程。整个工作流分为四个阶段：捕获、提炼、验证、报告。每个阶段都有明确的交付物和退出标准，避免陷入“抓了一堆包，却不知道扫什么”的混乱。

4.1 阶段一：定向捕获——用Fiddler的Filters和AutoResponder锁定目标域

盲目开启Fiddler抓全量流量，结果往往是：1小时抓出5万个会话，其中4.8万是广告、统计、CDN资源。移动端尤其如此，一个启动过程就触发几十个第三方SDK请求。我们必须用Fiddler的Filters功能做第一道筛选。

操作步骤：

1. 在Fiddler菜单栏点击Rules → Customize Rules，打开CustomRules.js；
2. 在OnBeforeRequest函数里添加域名白名单：

if (!oSession.HostnameIs("your-app-domain.com") && !oSession.HostnameIs("api.your-backend.com") && !oSession.HostnameIs("static.your-cdn.com")) { oSession["ui-hide"] = "true"; // 隐藏非目标域名 }

3. 启用Filters → Use Filters，勾选“Show only the following Hosts”，填入your-app-domain.com,api.your-backend.com；
4. 关键一步：启用AutoResponder，添加规则*.js→Disabled，阻止JS文件加载（减少干扰流量，同时迫使App用Native逻辑而非JS渲染）。

这样配置后，Fiddler界面只显示目标域名的请求，且JS资源被禁用，App会更多依赖Native组件，反而更容易暴露核心API。我测试某新闻App时，关闭JS后，原本隐藏在/api/v1/feed?category=top里的推荐算法接口，直接在首页加载时就暴露出来了——因为Native层直接调用了这个接口。

交付物：一个精简的Fiddler.saz文件，大小控制在5MB以内，包含从App启动到完成核心业务（如登录、查看订单、提交支付）的全部有效请求。退出标准：文件中/api/**路径的请求数≥50条，且至少包含3种HTTP Method（GET/POST/PUT）。

4.2 阶段二：智能提炼——从原始请求中提取可扫描的“种子URL”

Fiddler导出的URL列表不能直接喂给Nuclei。原因有三：一是大量URL带动态参数（?t=1712345678901&v=2.3.1），这些参数对扫描无意义；二是重复路径（/api/v2/user/profile出现20次，但参数不同）；三是无效路径（/api/v1/health这种心跳接口）。

我的提炼脚本（Python）逻辑如下：

import re from urllib.parse import urlparse, parse_qs def clean_url(url): parsed = urlparse(url) # 移除时间戳、版本号、随机数等无意义参数 clean_params = {k: v for k, v in parse_qs(parsed.query).items() if k not in ['t', 'v', 'r', 'ts', 'random']} # 重构query string，保持参数顺序一致（避免同一URL被当成多个） clean_query = '&'.join([f"{k}={{param}}" for k in sorted(clean_params.keys())]) return f"{parsed.scheme}://{parsed.netloc}{parsed.path}?{clean_query}" # 读取Fiddler导出的URL列表 with open('fiddler_urls.txt') as f: urls = [line.strip() for line in f if '/api/' in line] # 去重并清洗 seed_urls = set() for url in urls: clean = clean_url(url) if '/health' not in clean and '/metrics' not in clean: seed_urls.add(clean) # 输出为Nuclei可读格式 with open('nuclei_seeds.txt', 'w') as f: for u in seed_urls: f.write(f"{u}\n")

这个脚本的关键是：用{{param}}占位符代替真实参数值，既保留了URL结构，又消除了动态干扰。比如/api/v2/user/profile?uid=1001&t=123456变成/api/v2/user/profile?uid={{param}}，Nuclei扫描时会自动用payload替换{{param}}。同时，脚本过滤掉/health、/metrics等运维接口，避免浪费扫描资源。

交付物：nuclei_seeds.txt，内容为清洗后的种子URL列表，行数≤200。退出标准：列表中每个URL都应有明确的业务含义（如/user/profile、/order/create），不能出现/api/v1/xxx这种模糊路径。

4.3 阶段三：精准验证——用Nuclei的Matchers和Extractors定位真实漏洞

Nuclei扫描不是“扫完就交差”，而是要区分“告警”和“漏洞”。很多扫描器把401、403、500都标为“异常”，但实际可能是正常业务流。我们必须用Matchers精准定义“什么是漏洞”。

以越权漏洞为例，标准定义是：“非授权用户能访问到其他用户的敏感数据”。所以Matcher不能只匹配200 OK，而要匹配响应体中的敏感字段。比如：

matchers: - type: word words: - '"phone":"1' - '"id_number":"' - '"bank_card":"' condition: or - type: status status: - 200

这个Matcher要求：响应状态码是200且响应体包含手机号、身份证号或银行卡号字段。如果只匹配200，那么/api/v1/health也会被标为“漏洞”。

更进一步，用Extractors提取具体值，用于后续验证。比如上面模板中提取phone，可以在另一个模板里引用：

requests: - method: GET path: - "{{BaseURL}}/api/v2/user/info?uid={{extracted.phone}}" # 这里用上一步提取的phone值作为uid，验证是否能循环访问

这种链式提取，能把单点扫描升级为业务流扫描。我处理过一个案例：第一步提取到{"user_id":1001,"role":"admin"}，第二步用user_id=1001去请求/api/v2/admin/config，第三步检查响应中是否包含数据库连接字符串——三步串联，才构成完整的越权漏洞证据链。

交付物：一份Nuclei扫描报告（JSON格式），其中每个matched-at字段都附带extracted数据。退出标准：报告中severity: high/critical的条目，必须有extracted字段且值非空，否则视为误报，不予提交。

4.4 阶段四：结构化报告——用Markdown模板固化漏洞复现路径

最终的漏洞报告，不能是Nuclei的原始JSON，而要转化为开发能快速理解、测试能一键复现的文档。我用的Markdown模板包含五个固定区块：

1. 漏洞位置：精确到Fiddler会话编号（如#12345），附截图（红框标出URL和响应）；
2. 复现步骤：分三列表格，左列“操作”，中列“Fiddler中看到的”，右列“预期/实际结果”；
3. 技术细节：用代码块展示原始请求、修改后的PoC请求、响应体关键片段；
4. 风险等级：按CVSS 3.1标准计算（如AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N → 7.5高危）；
5. 修复建议：具体到代码行，如“在UserController.java第45行添加@PreAuthorize("hasRole('USER') and #uid == principal.id")”。

这个模板的价值在于：它把扫描器的机器输出，翻译成了人的语言。开发拿到报告，不用装任何工具，直接复制表格里的curl命令就能复现；测试可以按步骤在Fiddler里重放，验证修复效果。我坚持用这个模板三年，平均每个漏洞的修复周期从5天缩短到1.2天，因为沟通成本降到了最低。

交付物：一份.md格式的漏洞报告，包含上述五个区块，且每个区块都有真实数据支撑。退出标准：报告中所有curl命令，必须能在另一台未配置代理的电脑上，用curl -x http://fiddler-ip:8888成功执行并复现漏洞。

5. 实战避坑指南：那些只有亲手做过才会知道的细节

前面讲的都是“应该怎么做”，现在说说“千万别怎么做”。这些坑，是我和团队在20+个App渗透项目中，用真金白银的时间踩出来的。有些坑看起来很小，但足以让整个扫描流程卡死三天。

5.1 坑一：Fiddler的“Decrypt HTTPS traffic”开关，必须在抓包前开启

这是最反直觉的坑。很多人习惯先抓包，看到目标请求后再右键“Decrypt HTTPS traffic”。结果发现：之前抓的HTTPS请求，响应体全是乱码，无法解析。因为Fiddler的HTTPS解密是“实时解密”，不是“事后解密”。它只对开启开关后的新建TCP连接生效，对已建立的连接无效。

正确姿势：在Fiddler启动后，第一时间点击Tools → Options → HTTPS，勾选“Decrypt HTTPS traffic”，并点击“Actions → Trust Root Certificate”安装证书。然后再配置手机代理。这样所有后续流量都会被解密。如果已经抓了一堆乱码，唯一办法是清空Fiddler会话列表，重启Fiddler，重新操作。

注意：开启此选项后，Fiddler会成为中间人，某些App的证书固定（Certificate Pinning）会直接崩溃。此时需用Frida绕过pinning，但那是另一个话题了。

5.2 坑二：Nuclei的-rate-limit参数不是“限速”，而是“并发请求数”

文档里写-rate-limit 100意思是“每秒最多100个请求”，但实际是“最多同时发起100个并发请求”。这对移动端接口是灾难性的——服务端瞬间收到100个带相同Token的请求，风控系统直接封禁该Token，后续所有扫描都失败。

真实场景下，移动端API的QPS（每秒查询率）通常≤5。所以-rate-limit应设为5，而不是100。更稳妥的做法是加-timeout 30（单请求超时30秒）和-retries 1（失败不重试），避免因网络抖动导致误报。我在扫某社交App时，用默认的100并发，结果扫到第3个请求就被返回{"code":429,"msg":"Too many requests"}，后面97个全是429，白白浪费时间。

5.3 坑三：Fiddler导出的URL，必须用-u参数传给Nuclei，不能用-l

Nuclei的-l urls.txt是“从文件读取URL列表”，而-u url是“扫描单个URL”。看似一样，但-l模式下，Nuclei会为每个URL单独初始化一次HTTP Client，包括重建TLS连接、重置Cookie Jar。而移动端接口严重依赖会话连续性——/login返回的Cookie，必须在下一个/profile请求中携带。

用-l会导致：第一个URL（/login）成功，但第二个URL（/profile）因Cookie丢失返回401。正确做法是：用Fiddler的“Copy as cURL”功能，把登录成功的请求复制成curl命令，提取出Cookie和Authorization，然后用-H参数手动注入到Nuclei扫描中：

nuclei -u "https://api.example.com/api/v2/profile" \ -H "Cookie: JSESSIONID=abc123; token=xyz789" \ -H "Authorization: Bearer xyz789" \ -t templates/mobile/

这样所有请求都共享同一个Header上下文，模拟真实用户行为。

5.4 坑四：别信Fiddler的“Response Body”标签页，要看“TextView”或“HexView”

Fiddler默认的“Response Body”会自动解码gzip、解密Base64、渲染HTML，看起来很友好。但这也意味着：如果响应是Content-Encoding: gzip，你看到的是解压后的内容；如果是Content-Type: application/json，Fiddler会自动格式化JSON。问题来了——某些App的响应体是加密的（如AES-CBC），Fiddler会把它当普通文本渲染，你根本看不出它是密文。

正确做法：右键响应→“Inspect in New Window”，在新窗口中切换到“TextView”标签页，这里显示原始字节流；或者切到“HexView”，看十六进制。如果看到大量00 00 00 00或FF FF FF FF，基本可以确定是加密数据。这时，扫描器必须先解密再分析，否则所有Matcher都会失效。我处理过一个金融App，它的/api/v3/transaction响应是AES加密的，Fiddler“Response Body”显示乱码，但“HexView”里能看到明显的PKCS#7填充特征（末尾是08 08 08 08 08 08 08 08），这就锁定了加密算法。

6. 最后一点体会：工具只是杠杆，真正的扫描能力在人脑里

写完这篇教程，我回看自己最早做的移动端扫描——那时只会用Fiddler抓包，看到/api/user/delete就兴奋地以为找到删除接口，结果点进去发现是“删除本地缓存”，跟服务器毫无关系。后来学会用Burp重放，又陷入另一个误区：把所有401、403都当成“未授权访问漏洞”，却没意识到这是App的正常鉴权流程。

真正的突破，发生在我开始问“为什么”之后：为什么这个接口一定要带X-Device-ID？为什么/login返回的Token，30分钟后就失效，但/refresh能续期？为什么/order/create的响应里，order_id字段总是以ORD-开头，而user_id是纯数字？这些问题的答案，藏在App的业务逻辑里，不在工具的文档里。

所以，与其花时间研究“哪个扫描器最新版支持WebSocket”，不如多花一小时，把Fiddler里抓到的10个核心请求，手动在Postman里重放一遍，记录每次修改参数后的响应变化。你会发现：/user/profile?uid=1001返回张三的信息，uid=1002返回李四的信息，但uid=abc返回{"code":400,"msg":"invalid uid format"}——这说明服务端做了类型校验，不是简单SQL注入；而/order/create里amount=1000成功，amount=-1000返回{"code":403,"msg":"amount must be positive"}，说明有业务层校验，不是越权。

工具永远在变，Fiddler会出新版本，Nuclei会更新模板，但“理解业务→抽象模型→设计验证→分析结果”这个思维链条不会变。我现在的习惯是：每次拿到新App，先不急着开代理，而是用手机录屏，边操作边语音解说“我现在点这个按钮，App应该去请求哪个接口，为什么”。录完回放，把解说词整理成文字，再对照Fiddler日志找匹配项。这个过程慢，但建立起来的业务直觉，是任何自动化工具都替代不了的。

如果你刚入门，记住这句话：Fiddler是眼睛，Nuclei是手，而你的大脑，才是决定往哪里看、往哪里打的指挥官。