我要投稿

自学习机制下的 API 资产分类实践

发布日期：2026-04-15 12:20:50 浏览次数： 1525

作者：货拉拉技术

微信搜一搜，关注“货拉拉技术”

关键词：API 安全、资产分类、特征工程、自学习

一、背景（Why）

货拉拉现网支撑着海量域名与 API 接口的日常调用，涵盖公开、内部及第三方等多维场景。面对每日极为庞大的请求流量，我们的 API 体系规模仍在保持稳步扩张。API 作为承载应用程序的核心业务逻辑和敏感数据的角色，资产庞大形式多样，理论上每个 API 都可能是潜在的安全风险敞口，随着业务的发展网络安全团队面临的矛盾除了要解决“如何防护”，还需要更前置的理清楚要“防护什么”。

由此引出了本次分享的主要背景：API 安全主题下资产分类实践，如何给 API 贴上业务标签——注册、登录、订单交易等，有了资产分类标签，后续异常检测、基线告警工作才能“对症下药”。

🔐 注册/登录接口 → 防批量注册、暴力破解

📱 短信验证码接口 → 防短信轰炸、验证码爆破

📦 订单接口 → 防薅羊毛、恶意刷单

📁 文件传输接口 → 防敏感文件泄露

二、现状（What）

给定一条 API 的元信息（URL、Method、请求头、请求体、响应体等），预测其所属的业务标签。

url              : https://uapi.example.com/v1/user/login  method           : POST                                    host             : uapi.example.com                        api              : uapi.example.com/?_m=login              request_headers  : {"Content-Type":"application/json",...}  request_body     : {"username":"xxx","password":"xxx"}      response_body    : {"code":0,"msg":"success","token":"..."}response_headers : {"Set-Cookie":"...","Server":"nginx"}

这是一个典型的多分类任务，主流的资产分类方案：

首要面临的是样本标签稀少、类别不平衡问题。标签从哪里来？我们在先前的专项治理中有过零散的涉及，依靠人工筛选打标，有时动辄还会拉上多个业务方协助，过程中积累了多个业务场景下的宝贵的基础核心标签数据。但是 API 数量庞大且伴随业务迭代更新，长期角度来看过度依靠人工标记不可持续。

为此，我们构建一套自动化、可自我迭代的分类系统机制，实践的内容包括特征工程迭代和自学习标签回流机制，最终实现了置信度 ≥ 95% 的 API 标签约 10,000 个、模型精度提升 5 个百分点的落地成果。

三、实践（How）

特征工程：从“数据说话”到“知识引导”

API 请求数据通常包含 URL、请求头（headers）和请求体（body），这些字段既包含业务语义，也包含大量噪声。

v1：暴力枚举 Key

基于不同的业务下的 API，请求和响应的 JSON key 不同且具有差异的假设，如下图，通过暴力提取左图头部和 body 数据中的 key （右图）合成 One-Hot 向量直接给分类模型，这样每个 API 都有一个高维稀疏的特征向量。

实际中，V1 版本特征工程反馈了重要的缺陷：高维稀疏的 0-1 特征向量维度数等于所有出现过 key 的数量，意味着上万个 key 中存在大量的噪声，比如 data、code 这类的常见的 key 在每个 API 下都有出现；由于把递归提取的唯一 key 作为特征向量，如果新的 API 中出现了新的 key，模型几乎没有泛化能力，而且复杂度特别高。

比如，训练集中所有注册接口恰好包含 invite_code 的 key，模型学到了 invite_code=1 -> 注册的信号，但线上遇到一个没有 invite_code 的 key 注册接口时，模型就会误分类。建模初期，在样本数量和类目不多的情况下，用这种方法可以快速验证，训练数据拟合效果很好，准确率 80%+，F1 值表现较差。

v2：手动构造 + 业务关键词列表

考虑到暴力枚举 key 存在的维度爆炸和泛化差的缺陷，在 v2 特征工程构建中参考了人工在手动给 API 打标签的经验，通常会观察 url 结构特征，比如长度、查询参数个数，又比如会考虑请求头、请求体中的参数，包含设备参数、用户参数更有可能是订单交易类业务，还有考虑到 url 的路径深度、参数数量、特殊字符 "-", "_", "?", "=", "&", "/", "." 分布特征。新增了布尔和计数类型特征。

# URL基础统计url_length = len(url)                              # URL总长度url_depth  = len(path)                             # 路径深度url_params_counts = len(query_params)              # 查询参数个数
# URL特殊字符统计special_chars = ["-", "_", "?", "=", "&", "/", "."]special_chars_count = [url.count(char) for char in special_chars]
# URL关键词匹配（精确词边界匹配）pattern = r'\b' + re.escape(keyword) + r'\b'exists = 1if re.search(pattern, url_lower) else0counts = len(re.findall(pattern, url_lower))

除此之外，v2 在 9 个业务类别下定义了关键词词典来捕捉最强的业务信号，并且在关键词匹配上做了跨源匹配。同一个关键词在不同字段出现代表了不同的信号，比如 login 出现在 url 中是非常强的信号，如果出现在响应体的某个字段中则比较弱。

business_keywords = {    "register": ["register", "join", "signup", "enroll", ...],    "login":    ["login", "auth", "logout", "account"],    "sms_code": ["send", "sms", "verification", "phone"],    ...}

对比 v1，该版本的特征向量维度从上万维降低到几百维，在维度下降的情况下，利用从 url 字段提取的统计特征解决了泛化能力差的问题。通过引入业务词典、url 结构特征、请求头特征工程组合，我们将少数类 F1 从 0.25 左右提升到 0.80 以上，整体准确率达到 90%，泛化能力显著提升，但关键词词典需要持续维护。

v3：文本 + 统计特征混合

v2 版本的特征工程参考了手工打标，引入了人工维护的关键词词典，用一种精确匹配的方法理解 API 的请求数据而没有利用语义理解，比如订单交易类别的业务中，order_detail 和 orderDetail 代表了两种不同风格却属于同一个类别的 API，通过维护关键词词典捕捉这类的信号成本很高。

前面提到其实不断维护关键词特征成本会越来越高，如果可以将 API 请求参数数据序列化为文本，让模型自己去学习其中的语义信息，那么问题就可以迎刃而解。

CatBoost 原生支持 text_features 参数，能够自动从文本列中学习 BoW / TF-IDF / 嵌入特征，将 URL path、request body 的 key、response body 的 key 拼接成一个统一的文本字段。例如对于一个注册接口，生成的文本可能是：

v1 user register username password invite_code code msg data token

CatBoost 的文本处理器会自动对这段文本做分词、统计 TF-IDF、构建词袋特征，甚至可以学习词的组合模式（n-gram），构建的特征信息流如下：