【 第 5 步 】

接口检查室

师傅:“页面上看到的数据只是系统的一部分,今天我们专门检查系统之间自动交换数据的接口。尼娅面包厂的会员系统会调用短信服务发送验证码,配送系统向物流公司传输配送信息,客服系统还会调用CRM接口。

接口能够持续、自动、批量传输数据,所以必须单独检查。我们按照九项内容分析:调用主体、业务目的、请求和返回字段、认证、加密、访问控制、调用频率、日志和异常处置

尤其要注意:页面可能只显示脱敏手机号,但接口却可能返回完整字段。还要检查令牌、证书和密钥如何使用,以及是否有限流、撤销、轮换和告警能力。”

接口检查室情景阅读暂用场景图

01 · 现场对话

接口检查室的知识任务

01

先看谁在调用谁

接口首先要明确主体。

师傅

“这个物流接口是谁调用?”

开发人员

“配送系统调用第三方物流服务。”

小白

“负责人是谁?”

开发人员

“配送系统由信息部负责,物流接口有指定供应商联系人。”

师傅

“先把双方主体写清楚。”

02

再看请求和返回字段

页面和接口可能不同。

小白

“配送接口发送姓名、手机号和地址,这几个字段和配送目的有关。”

师傅

“还有没有别的?”

开发人员

“现在还会发送会员生日。”

小白

“生日和配送好像没有直接关系。”

师傅

“列入字段最小化检查。”

03

检查接口怎么证明身份

自动调用也需要认证。

小白

“接口怎么知道是我们的配送系统?”

开发人员

“使用令牌。”

师傅

“令牌有没有期限、轮换和撤销机制?”

小白

“还要检查来源限制和加密传输。”

04

最后看频率和日志

异常调用需要能够发现。

小白

“正常一天调用大约2000次。”

师傅

“如果突然一分钟调用1万次呢?”

小白

“应该有限流或告警。”

师傅

“日志还要记录调用方、时间、接口、结果和异常。”

02 · 小白做现场笔记

重要概念及注释

01

接口数据处理

正式含义
系统通过接口自动向其他系统或第三方请求、返回或交换数据。
接口是评估重点,因为数据可能:
自动 持续 批量
地进行传输。

页面是人看到的数据,接口是系统之间自动交换的数据。

02

接口分析核心项

基础检查
谁调用? 为什么调用? 请求什么字段? 返回什么字段? 怎样认证? 有没有加密? 权限怎样限制? 调用多频繁? 有没有日志? 异常怎样处理?
教材的接口分析表也重点记录调用方、字段、认证加密、频率限流和日志审计。

接口评估要同时看“谁在调、传什么、调多少、怎样控制”。

03

请求字段与返回字段

正式含义
请求字段是调用方发送给接口的数据;返回字段是接口处理后返回的数据。
面包厂场景
物流接口:
请求 → 订单号 返回 → 配送状态
如果接口额外返回:
完整会员信息 生日 历史订单
就需要检查是否超出目的。

接口不仅要检查“传进去什么”,也要检查“返回出来什么”。

04

接口最小化

正式含义
根据业务目的,把接口请求和返回字段控制在实际需要的最小范围。
测试方法
列出业务真正需要的字段 ↓ 使用不同角色调用 ↓ 检查实际返回 ↓ 检查页面没有显示的字段 ↓ 检查批量和分页上限
教材特别要求检查接口是否返回页面未显示的敏感字段。

页面做了脱敏,不代表接口后面没有偷偷返回完整数据。

05

接口认证

正式含义
用于确认接口调用方真实身份的机制。
基础要求
不同调用方使用独立身份 令牌有有效期 定期轮换 支持吊销 凭证泄露可以应急处理
高风险接口可以组合:
证书 + 签名 + 来源限制 + 令牌
教材同时强调,完整密钥不应写入日志、普通文档或公开代码仓库。

系统调用系统,也需要先证明“我是谁”。

06

接口频率与限流

正式含义
限制单位时间内接口可以被调用的次数、并发量或批量数据量。
面包厂场景
平时:
每分钟几十次查询
突然:
一分钟1万次
需要:
限流 告警 日志分析

单次访问正常,不代表一万次连续访问也正常。

07

接口日志

至少记录
调用方 调用时间 接口名称 执行结果 异常情况
同时避免日志本身保存完整密钥或不必要的敏感内容。

接口自动运行得越快,越需要日志告诉我们到底发生过什么。

08

密钥与令牌生命周期

工作路线
生成 / 发放 ↓ 使用 ↓ 保存 ↓ 轮换 ↓ 异常吊销 ↓ 到期撤销

密钥和令牌不是“生成以后一直用”,也有自己的生命周期。

03 · 经验和难点

小结

这一站,小白从调用主体、目的、字段、认证、加密、权限、频率、日志和异常处置九个方面完成了一次接口检查。最值得记住的经验是:接口要单独评估,因为它可能自动、持续、批量传输页面上看不到的数据。初学者最容易遇到的难点,是只检查前端页面显示内容,却忽略接口实际返回的完整字段和调用范围。