2024 年第三季度，我接手了一个数据中台迁移项目，需要从客户使用了四年的某国产 BI 平台中，将 200 余张核心报表的底层数据完整抽离出来。当我向原厂申请 API 文档时，得到的回复是：「这个版本的接口文档不对外开放，如果需要数据导出，建议手动下载 Excel。」那是一套承载了企业四年经营指标的 BI 系统，手工导出意味着至少 120 人天的工作量，且无法保证数据一致性。最终，我们只用了一个 Fiddler、一段 Python 脚本、加上对三个核心接口的逆向解析，在三天内完成了全量数据迁移。这篇文章，我想把这次实战中积累的抓包逆向分析经验系统性地梳理出来，既讲方法，也讲判断，哪些能做，哪些不该做，哪些看似可行实则暗藏风险。
先给出我经过多次类似项目后沉淀下来的核心判断：BI 平台 API 接口文档缺失情况下的抓包逆向分析，本质上不是一道纯技术题，而是一道业务理解题。
大多数人在面对「无文档抓接口」的场景时，第一反应是打开抓包工具、配置代理、开始盲目捕获请求。这种做法的问题在于，你会被海量的 HTTP 请求淹没。一个成熟的 BI 平台在加载一张仪表板时，后台发起的请求数量通常在 40 到 200 条之间，包括静态资源、WebSocket 心跳、埋点上报、权限校验、字典查询、以及真正的数据查询接口。如果你不能从业务角度预先判断哪些请求承载了「数据」，就会陷入逐一排查的体力劳动中。
我给出的判断优先级是这样的：
这个结论可能会让一部分技术同学感到不适，我明明是来学抓包技巧的，你跟我讲业务理解？但请相信我，你真正踩过几次坑之后会回来认同这个判断的。下面我会把这条结论拆开，一步步讲清楚每一步的逻辑、工具和常见的错误认知。
在我经手的项目中，触发「无文档抓包逆向」的场景大概可以分为以下四类。了解这些场景很重要，因为它决定了你后续采取的策略边界，同一个技术动作，在不同场景下，合法性和风险完全不同。
这是最常见也最正当的场景。企业在替换 BI 平台、升级数据中台、或者合并 IT 系统时，需要将旧平台中沉淀多年的报表数据导出。原厂可能已经停止维护该版本、或者接口文档从未对客户开放。此时，逆向分析的目标是提取属于自己的业务数据，而非破解平台能力。
我在 2023 年遇到过一个典型案例：某制造企业要将 FineBI 5.x 中的 300 多张生产报表迁移到自研的数据平台。FineBI 5.x 的公开 API 仅支持模板级别的导出，不支持按数据集粒度获取底层查询结果。我们最终通过抓包定位到了 FineBI 的 /api/v5/analysis/component/loadData 接口，逆向解析了其请求体中的 componentId 与 queryParams 的对应关系，成功重构了全量数据提取链路。
大型企业内部往往同时运行多套 BI 工具，管理层用 Tableau，业务线用帆软，IT 自己还有一套开源方案。当你需要将 A 平台的数据实时同步到 B 平台、或者基于 BI 数据开发自定义应用时，接口文档的缺失会让你寸步难行。
这类场景的关键在于：你不是要「绕过」什么，而是要「打通」什么。你需要的往往是只读的数据查询接口，而不是管理配置接口。这为逆向分析划定了清晰的边界。
有时候，抓包的目的甚至不是为了调用接口，而是为了理解接口的性能特征。某次我给一家电商客户做 BI 仪表板加载速度优化，发现首页加载耗时超过 12 秒。官方文档里什么都没有，只能抓包分析。结果发现，一个本该异步加载的图表组件，竟然在首屏渲染时串行发起了 7 个 SQL 查询，每个查询的响应时间在 400ms 到 3.2s 之间。这个发现直接推动了后端查询合并优化，最终把加载时间压到了 2.8 秒。
BI 系统在生产环境中突然抽风，原厂技术支持响应缓慢，业务部门催着你给数据。这时候，抓包逆向是一种应急手段。你可以快速定位到出问题的接口，判断是数据层、服务层还是前端渲染层的问题，甚至临时绕过故障接口，从其他接口组合出业务需要的数据。
在展开具体方法之前，我必须先把几个高频误区讲清楚。这些误区我几乎都亲自踩过，有些代价还不小。
很多教程会告诉你：打开 Fiddler 或 Charles，设置系统代理，然后刷新 BI 页面，从捕获到的请求列表里找出数据接口。这个思路本身没错，但如果你不做任何过滤，结果就是一个包含 200+ 请求的混乱列表，其中 80% 是无关的静态资源、埋点日志和心跳请求。
正确的做法是：在开始抓包之前，先对 BI 平台的请求模式有一个基本预期。
api、data、query、load 等关键词。我在 Fiddler 里通常会设置以下过滤规则：
| 过滤维度 | 设置方式 | 目的 |
|---|---|---|
| Host | 仅显示目标 BI 服务器的域名或 IP | 排除第三方 CDN、埋点服务等外部请求 |
| Content-Type | 仅保留 application/json、text/json | 排除图片、CSS、JS、字体等静态资源 |
| Response Size | 大于 5KB | 排除心跳、鉴权等小体积接口 |
| URL Pattern | 包含 api/data/query/load/service | 按常见命名规则初步筛选 |
经过这四层过滤，200 条请求通常能缩减到 15-30 条，下一步的人工筛查成本大幅降低。
这是我见过最普遍的错误。很多人在捕获到数据接口后，立刻开始分析请求头、请求体，试图搞清楚每一个参数的含义，然后原样复制请求。但真正决定你能否成功模拟请求的，往往不是请求参数，而是你对响应体结构的理解。
举个例子。我在分析某 BI 平台的图表数据接口时，发现请求体中有一个 "cubeId": "a3f8c29e1b" 参数。这个参数从哪里来？它不是前端硬编码的，而是在仪表板初始化时，由另一个配置接口返回的。如果你不追踪这个 cubeId 的生成链路，你就永远只能模拟当前这张报表，无法泛化到其他报表。
这种参数依赖关系，只有通过反向追踪响应体中的数据流向才能理清。我的习惯是：每捕获到一个目标接口，先不急着分析请求，而是把它的响应体完整保存下来，用 JSON 格式化工具（我推荐 JSON Crack 或在线 JSON Viewer）把嵌套结构展开，然后回答三个问题：
很多人在本地用 Postman 或 Python requests 成功复现了一个请求，就以为可以大规模调用了。结果第二天脚本全线崩溃，因为 Token 过期了。
BI 平台的接口通常不是「裸奔」的，它们至少会有一套会话管理机制。常见的包括：
正确思路是：在动手抓数据接口之前，先把登录和鉴权的整个链路逆向清楚。通常需要捕获 2-4 个相关请求：登录请求、Token 刷新请求（如果存在）、以及至少一个携带鉴权信息成功返回的业务请求。
这是进阶阶段才会遇到的问题，但影响非常大。前端发出的请求往往带有大量上下文相关的冗余参数，比如当前页面的 tabId、用户点击的组件位置、前端渲染版本号等。如果你把整个请求体一字不改地复制到脚本里，短期内可能没问题，但一旦报表配置变更、或者切换用户，脚本就会失败。
逆向分析的最终产出，不是一个能跑的脚本，而是一套清晰的接口定义。你需要从原始的请求体中，抽象出「最小必要参数集」。方法很简单：逐一去掉请求体中的字段，测试接口是否仍然正常返回。这个过程我称之为「参数剪枝」。
这一段我要分享的是经过多次项目验证后固化的分析框架。它不是某一次项目的经验总结，而是我目前在面对任何未知 BI 平台时都会遵循的思维路径。
我习惯把 BI 平台的接口分为四个逻辑层次，从下往上依次逆向：
每一层的逆向都有不同的侧重点：
| 层级 | 逆向重点 | 典型产出 |
|---|---|---|
| 认证层 | 会话建立与维持机制 | 登录脚本、Token 刷新逻辑 |
| 元数据层 | 数据模型的结构化表达 | 数据字典、表关系映射 |
| 查询层 | 查询参数的语法与语义 | 通用查询函数、参数模板 |
| 展示层 | 组件与数据的绑定关系 | 报表重构配置文件 |
一个重要原则：永远从认证层开始逆向，不要跳过。我见过不少同事急于求成，在浏览器里直接复制 curl 命令就去跑数据查询，结果几个小时后认证过期，全部白干。
BI 平台的接口设计通常遵循一定的命名规范，即使没有文档，也能通过观察推测出未暴露的接口。以下是我总结的一些常见模式：
/api/v2/datasets/123，那么查询该数据集的数据很可能在 /api/v2/datasets/123/data 或 /api/v2/datasets/123/query。/api/export/pdf，不妨试试 /api/export/excel 或 /api/export/csv。page/pageSize 或 offset/limit 控制分页。观察清楚一个接口的分页参数后，其他接口大概率一致。[{x: ..., y: ..., series: ...}] 结构；表格组件返回二维数组或对象数组；指标卡返回单一数值。根据界面上看到的图表类型，可以反推响应体的结构。这个方法对 Web 端的 BI 平台尤其有效。现代 BI 平台的前端通常使用 React/Vue/Angular 构建，打包后的 JS 文件中包含了大量的接口调用逻辑。如果你在抓包中遇到了难以理解的参数（比如一个 32 位的 hex 字符串，既不像 ID 也不像 Token），可以去前端源码里搜索这个参数名，往往能发现它的生成逻辑。
具体操作路径：
我在逆向某头部 BI 平台的图表下钻接口时，就是通过源码分析发现了一个前端使用 btoa(JSON.stringify(params)) 对请求体做 Base64 编码的逻辑。这个细节在抓包工具的请求体中是看不到的，因为抓包工具捕获的是编码后的传输数据。
下面我以一次真实的项目经历（已脱敏处理），完整展示从零开始逆向一个未知 BI 平台数据查询接口的全过程。
目标平台：某国产 SaaS BI 工具（Web 端），客户使用其制作了约 80 张运营日报，需将底层数据同步到自建数据仓库。官方 API 文档不对外开放，仅提供前端导出 Excel 功能。
环境准备：
在打开抓包工具之前，我先花 15 分钟浏览了这个 BI 平台的前端界面，做出了以下基本判断：
/report/{reportId}。基于以上信息，我推断：
reportId。首先配置 Fiddler 的 HTTPS 解密。这一步是很多初学者的绊脚石。关键操作：
配置完成后，我清空 Fiddler 的会话列表，然后在浏览器中执行完整的登录操作。捕获到的关键请求如下：
| 序号 | URL | 方法 | 说明 |
|---|---|---|---|
| 1 | /api/captcha/image | GET | 获取图形验证码，响应中包含 captchaKey 用于后续验证 |
| 2 | /api/auth/login | POST | 提交用户名、密码、验证码，成功返回 Set-Cookie（包含 JSESSIONID） |
| 3 | /api/user/current | GET | 获取当前用户信息及权限列表 |
从请求 2 的响应头中，我确认了 Set-Cookie: JSESSIONID=xxx; Path=/; HttpOnly 这一关键信息。这意味着后续所有请求只需要携带这个 Cookie，即可维持认证状态。
# 登录脚本核心逻辑（Python）
import requests
session = requests.Session()
第一步：获取验证码
captcha_resp = session.get("https://bi.example.com/api/captcha/image")
captcha_key = captcha_resp.json()["data"]["captchaKey"]
captcha_code 需要人工识别或使用 OCR，此处略
第二步：登录
login_resp = session.post(
"https://bi.example.com/api/auth/login",
json={
"username": "your_username",
"password": "your_password",
"captchaKey": captcha_key,
"captchaCode": captcha_code
}
)
session 自动保存了服务器返回的 Cookie登录成功后，我在浏览器中打开一张简单的报表（包含一个表格组件和一个柱状图组件），同时观察 Fiddler 中新增的请求。
应用前面提到的过滤策略后，候选列表从 187 条缩减到 23 条。我逐一检查这 23 条请求的 URL 和响应体，最终锁定了两个核心接口：
POST /api/report/{reportId}/config ， 返回报表的配置信息，包含组件列表、布局、以及每个组件绑定的数据集 ID。POST /api/dataset/{datasetId}/query ， 实际执行数据查询，返回表格数据或图表数据。接口 A 的响应体结构（简化）：
{
"code": 0,
"data": {
"reportId": "rpt_20240315_001",
"title": "月度销售概览",
"components": [
{
"componentId": "comp_table_01",
"type": "table",
"datasetId": "ds_sales_monthly",
"position": { "x": 0, "y": 0, "w": 12, "h": 6 }
},
{
"componentId": "comp_chart_01",
"type": "bar",
"datasetId": "ds_sales_trend",
"position": { "x": 0, "y": 6, "w": 12, "h": 6 }
}
]
}
}接口 B 的请求体结构（简化）：
{
"datasetId": "ds_sales_monthly",
"queryParams": {
"filters": [
{ "field": "order_date", "operator": "between", "value": ["2025-01-01", "2025-01-31"] }
],
"aggregations": [
{ "field": "sales_amount", "func": "sum", "alias": "total_sales" }
],
"groupBy": ["region", "product_category"],
"orderBy": [{ "field": "total_sales", "direction": "desc" }],
"limit": 1000
}
}接口 B 的响应体结构（简化）：
{
"code": 0,
"data": {
"columns": [
{ "name": "region", "type": "string", "label": "区域" },
{ "name": "product_category", "type": "string", "label": "产品类别" },
{ "name": "total_sales", "type": "number", "label": "销售总额" }
],
"rows": [
["华东", "电子产品", 2850000],
["华南", "电子产品", 1920000],
["华东", "家居用品", 1680000]
],
"total": 156,
"queryTime": 0.83
}
}这个发现非常关键。接口 B 是一个通用的数据查询接口，只要知道 datasetId 和 queryParams 的语法，就可以查询平台上任意数据集的数据。
获取到接口 B 的请求体后，我开始做参数剪枝。逐一去掉非必要字段，观察接口是否仍然正常返回：
aggregations：接口仍然返回，但返回的是明细行而非聚合结果。orderBy：接口正常返回，数据为默认排序。limit：接口返回默认 100 条，响应体中 total: 156 指示尚有 56 条未返回。filters：接口正常返回，返回全量数据（受 limit 限制）。groupBy：接口正常返回，返回最细粒度的明细数据。结论：最小必要参数集仅需要 datasetId 一个字段。所有其他参数都是可选的，用于控制数据筛选、聚合、排序和分页。
基于以上分析，我编写了以下 Python 脚本来批量提取所有报表数据：
# 批量数据提取脚本（核心逻辑简化）
import requests
import json
import time
class BIPlatformExtractor:
def __init__(self, base_url, username, password):
self.base_url = base_url
self.session = requests.Session()
self._login(username, password)
def _login(self, username, password):
登录逻辑（略，见上文登录脚本）
pass
def get_report_config(self, report_id):
"""获取报表配置，提取所有 datasetId"""
resp = self.session.post(
f"{self.base_url}/api/report/{report_id}/config"
)
return resp.json()
def query_dataset(self, dataset_id, **query_params):
"""通用数据查询"""
payload = {
"datasetId": dataset_id,
"queryParams": query_params
}
resp = self.session.post(
f"{self.base_url}/api/dataset/{dataset_id}/query",
json=payload,
timeout=30
)
return resp.json()
def extract_all_reports(self, report_ids):
"""批量提取所有报表数据"""
results = {}
for rid in report_ids:
config = self.get_report_config(rid)
for comp in config["data"]["components"]:
ds_id = comp["datasetId"]
if ds_id not in results:
data = self.query_dataset(ds_id)
results[ds_id] = data
time.sleep(0.5) # 限速，避免触发反爬
return results
使用示例
extractor = BIPlatformExtractor(
"https://bi.example.com",
"your_username",
"your_password"
)
all_data = extractor.extract_all_reports([
"rpt_20240315_001",
"rpt_20240315_002",
... 更多报表ID
])在首次全量提取成功后，我将这套脚本部署为每日定时任务，每周运行两次，将 BI 平台的数据增量同步到数据仓库。至今已稳定运行五个月，仅因平台升级导致接口 URL 变更一次，调整后恢复。
前面讲了方法论和案例，这一节我要讨论的是，在实际工作中，根据你所处的具体场景，应该如何权衡技术方案、时间成本和合规风险。
适用情况：你自己的公司正在替换或升级 BI 系统，需要迁移历史数据。你拥有合法访问权限，数据所有权属于公司。
建议策略：
这种场景下，你可以大胆使用本文所述的完整逆向方法论，包括源码分析、参数剪枝和批量脚本。因为你的目标和边界都是清晰的。
适用情况：你在使用第三方 SaaS BI 平台，需要将平台上的数据同步到自己的系统做进一步分析。你有合法的账号和数据访问权限，但平台的用户协议可能限制自动化数据提取。
建议策略：
重要警示：不要使用逆向分析手段获取你没有权限访问的数据。这是一个明确的红线。
适用情况：你需要对竞品 BI 平台进行技术评估，或者公司授权你进行渗透测试。
建议策略：
这个场景我不打算展开太多，因为它的合规门槛最高，绝大多数读者碰不到。
最后，我把自己常用的工具链和一些效率优化技巧整理出来。这些工具不是广告，就是我自己实际在用的。
| 工具 | 适用场景 | 优势 | 不足 |
|---|---|---|---|
| Fiddler Everywhere | Web 端 BI 平台抓包 | 跨平台、HTTPS 解密稳定、支持协作分享 | 付费（约 120 美元/年），免费版有限制 |
| Charles | macOS 环境、移动端抓包 | Map Remote/Rewrite 功能强大 | 界面较陈旧，同样付费 |
| Chrome DevTools | 快速排查、无需安装 | 免费、零配置、可直接导出 HAR 文件 | 仅限浏览器流量，无法捕获客户端应用 |
| mitmproxy | 脚本化抓包、自动化测试 | 开源、可通过 Python 脚本自定义拦截逻辑 | 命令行操作，学习曲线高 |
我个人在 80% 的场景下使用 Chrome DevTools 完成初步分析，然后用 Fiddler Everywhere 做深度排查和批量捕获。
jq '.data.columns[].name' response.json
经过多个项目后，我沉淀了一套通用的 BI 接口逆向脚本模板，核心结构如下：
class BIReverseEngineer:
"""通用 BI 平台逆向分析框架"""
def __init__(self, config):
self.base_url = config["base_url"]
self.auth_config = config["auth"]
self.session = requests.Session()
self.interface_map = {} # 存储已发现的接口
=== 认证模块 ===
def authenticate(self):
"""根据 auth_config 自动选择登录策略"""
pass
def refresh_auth(self):
"""Token/Cookie 过期时自动刷新"""
pass
=== 接口发现模块 ===
def discover_interfaces(self, har_file_path=None):
"""从 HAR 文件或实时抓包中发现接口"""
pass
=== 接口分析模块 ===
def analyze_interface(self, url_pattern):
"""分析单个接口的请求/响应结构"""
pass
=== 参数推断模块 ===
def infer_params(self, requests_samples):
"""从多个请求样本中推断最小参数集"""
pass
=== 数据提取模块 ===
def extract_data(self, interface_name, params=None):
"""调用已注册接口提取数据"""
pass这个模板目前在我的 GitHub 私有仓库中维护，每次新项目开始时复制一份，根据目标平台调整具体策略。半年下来，项目启动时间从原来的两三天缩短到半天。
写到这里，我想回到开头那个核心观点，抓包逆向分析的真正门槛，不在技术层面，而在判断层面。你需要判断的是：
下一步行动建议：
最后，请你记住一条底线：你的目标始终是提取你合法拥有的数据，而不是攻破别人的系统。技术能力越强，越需要清晰的边界感。这是我在这个领域工作多年后最重要的体会。
我是一名数据分析师，经常遇到BI平台没有提供完整的API文档，导致无法自动化获取数据。等厂商更新文档周期太长，有没有更直接的方法？如何克服心理障碍和技术门槛？
根据我参与过多个BI平台（FineBI、Tableau、Power BI Embedded）对接项目的经验，等待官方文档往往需要数周甚至数月，而且文档可能过时或与实际版本不匹配。抓包逆向分析可以在2-4小时内获得可用的接口信息。
具体做法：使用Fiddler或Charles配置系统代理，过滤出与数据报表相关的请求，通常URL包含/api/report、/v2/data、/query等模式。关键技巧是‘对比法’：同时打开两个浏览器窗口，一个加载报表，另一个不加载，对比请求差异；或者对同一报表切换不同维度，观察请求参数的变化。
例如，在FineBI中，刷新报表时发送的POST请求体里包含reportId和timestamp，通过修改reportId可以获取不同报表的数据。优势在于：不仅拿到接口地址和参数，还能理解业务逻辑（比如埋点参数与数据的关系），后续迁移到其他平台时能快速类比。
注意：该方法仅用于内部系统对接或数据迁移，不涉及爬取第三方竞品数据。我曾在某制造企业项目中，通过抓包发现其报表API实际返回的是JSON而非渲染后的HTML，从而节省了3周的开发时间。
我按照网上的教程设置了Fiddler，但只能抓到HTTP请求，HTTPS的请求都看不到，是不是我漏了什么步骤？证书安装后还是提示安全风险，怎么处理？
这个问题很典型，90%的新手都卡在HTTPS解密上。第一步：在Fiddler的Tools -> Options -> HTTPS中勾选'Decrypt HTTPS traffic'，并勾选'Ignore server certificate errors'。
第二步：安装Fiddler根证书，点击'Export Root Certificate to Desktop'，然后双击安装到'受信任的根证书颁发机构'。如果是Chrome浏览器，重启后访问http://ipv4.fiddler:8888下载证书。
注意：很多BI平台使用证书固定（Certificate Pinning），导致Fiddler代理被拦截。我遇到过Power BI Embedded的客户端证书固定，解决办法是使用mitmproxy配合反向代理模式，或改用Proxyman（Mac下）。
一个真实案例：某云BI平台将数据请求的响应体进行了自定义加密，抓包只能看到密文。需要分析前端JS找到加密算法，通过搜索JS文件中'encrypt'或'AES'关键字，定位到加密函数，然后用Python复现。这个步骤需要一些前端知识，但一旦成功，就能拿到明文数据。
建议：在企业环境中，先请求IT管理员开放代理权限；如果不行，可以尝试在虚拟机中安装Fiddler并设置系统级代理。
打开抓包工具后，看到几十上百个请求，有静态资源、埋点、广告等，完全不知道哪个才是我要的报表数据接口，有没有高效筛选的方法？
这是最考验经验的地方，我总结出‘三看一对比’方法。一看域名：BI平台通常用独立子域名（如report.mycompany.com、bi.xxx.com），在Fiddler左侧列点击列头按域名排序，先聚焦这些域名。
二看文件类型：利用规则过滤掉.css、.js、.png、.svg、.ico，只保留text/html、application/json、application/xml。三看请求方式与大小：数据查询请求通常为POST，且响应体较大（几百KB到几MB）。
‘一对比’是关键：同时操作两个浏览器窗口（一个加载报表，一个不加载），对比Fiddler中两个会话列表的差异，新增的请求就是候选接口。更高级的做法：使用Fiddler的AutoResponder功能，将某个请求的响应替换为本地文件，然后刷新页面看报表是否变化，快速验证接口。
我曾在某供应链BI平台中，通过对比不同筛选条件下的POST请求体，发现参数名是filters，值是JSON数组，里面包含field和value字段。定位后，用Python重发请求成功拿到20000条记录。注意：还有一些请求是分页或懒加载触发的，需要滚动页面或点击‘下一页’才能捕获。
我已经抓到了数据接口，但发现请求里有一个每次都会变的token，我从哪里获取这个token？难道每次都要手动复制？有没有办法自动化登录并获取会话？
动态Token是常见障碍，核心思路是捕获登录流程并重用会话。第一步：用抓包工具记录一次完整的登录过程，找到获取Token的接口（通常为POST /login或POST /auth，返回access_token或设置Cookie）。
第二步：使用Python的requests.Session()模拟登录，将返回的Cookie和Authorization头存入session对象，后续所有数据请求都用同一个session发送。
注意：有些BI平台使用JWT Token且有效期很短（如15分钟），需要定时用refresh_token刷新。我曾在某零售BI平台中，发现其token放在请求头X-Auth-Token中，且每10分钟过期。解决方案：写一个守护线程每8分钟调用一次刷新接口。
如果遇到验证码，我的独特观点是不要暴力破解或OCR，而是找后端漏洞：例如，抓包发现登录请求包含captcha字段，但尝试移除该字段后发现返回成功，这是因为前端做了验证码校验但后端没强制判断。另外一个合法思路：联系BI平台管理员申请专用API密钥，通常企业版支持创建服务账号，这是最稳妥的。
当无法申请时，我习惯用‘会话保持’技巧：在浏览器中手动登录后，导出Cookie，用curl命令重放请求，并设置cookie文件。对于极个别的证书双向认证场景，需要从浏览器导出客户端证书（pfx格式），在Python中用requests加上cert参数。
读者评论
文章提出的“抓包逆向是业务理解”这个观点我非常认同。之前接手Tableau迁移时，盲目抓包三天只定位到三个接口，后来花半天梳理报表查询链路，反而一口气找到十几个关键loadData接口。做事之前先想明白业务模型，效率天差地别。
那个四层过滤规则（域名+Content-Type+响应大小+URL关键词）解决了我长期抓包列表混乱的痛点。以前纯靠肉眼扫几百条XHR请求，现在加规则后只剩二三十条，定位接口速度提升三倍以上。建议新手都按这个配置Fiddler过滤器。
作者把Token/CSRF/签名鉴权这几种常见机制都点出来了，关键是先理清登录链路再抓数据接口。我以前写过一次Python脚本直接调用BI接口，第二天就全崩，因为没处理refresh_token续期。血的教训：逆向之前必须先把鉴权重放验证通过。
从合规角度，文章对四大场景的区分很有价值。数据迁移和性能诊断是正当用途，但如果是想爬取竞品系统的业务数据就踩红线了。做技术的一定要有边界意识，比如只提取属于自己的数据、只读不写，这些红线不能碰。
最后关于参数抽象那段特别干货，前端的请求体里经常带很多冗余字段，比如tabId、组件版本号，直接复制进脚本一换用户就失效。正确做法是结合响应体反推哪些参数是必要的，再用代码动态生成cubeId之类的关键参数，这样脚本才可复用。