一、接口安全概述：什么是接口适配、常见的安全威胁模型、安全设计的黄金法则
各位好，我是老周。今天开始咱们聊接口适配中的安全陷阱。这个系列一共30章，我会把这些年踩过的坑、总结的经验，一点一点掰开揉碎了讲。
先问个问题：你写接口的时候，有没有想过——为什么同样的接口，换个系统对接就出问题？为什么明明测试通过了，上线就被攻击？
说白了，接口适配不是简单的「你调我、我调你」。它背后藏着大量安全细节。我见过太多团队，接口联调时一切正常，一上线就被爬虫薅羊毛、被注入攻击打穿。嗯，今天咱们就从根上捋一捋。
1.1 什么是接口适配
接口适配，就是两个系统之间约定好通信方式的过程。你想想看，A系统用JSON，B系统用XML；A系统用HTTP/1.1，B系统用gRPC。怎么让它们顺畅对话？这就是适配要解决的问题。
我个人的习惯是，把接口适配分成三个层次：
| 层次 | 说明 | 常见问题 |
|---|---|---|
| 协议层 | HTTP、HTTPS、gRPC、WebSocket 等 | 协议版本不兼容、TLS配置错误 |
| 数据层 | JSON、XML、Protobuf、表单等 | 字段类型不匹配、编码不一致 |
| 语义层 | 业务含义、状态码、错误处理 | 状态码滥用、错误信息泄露 |
我在项目中遇到过最典型的例子：两个系统对接，A系统返回的「用户状态」字段是数字（0=正常，1=冻结），B系统却按字符串解析。结果「0」被当成「false」，「1」被当成「true」。上线第一天，所有正常用户都被判定为冻结。你说冤不冤？
核心观点：接口适配不是简单的格式转换，而是协议、数据、语义三个层面的对齐。任何一个层面出问题，都可能成为安全漏洞的入口。
1.2 常见的安全威胁模型
做接口安全，你得先知道敌人长什么样。我习惯用 STRIDE 模型来梳理威胁。这个模型是微软提出的，虽然老，但很实用。
我挑几个接口适配中特别容易中招的说说：
- 欺骗（Spoofing）：接口调用方伪造身份。比如盗用别人的Token来调你的接口。我在项目中遇到过，有人把别人的Session ID直接塞到请求头里，后端没校验来源，结果数据全被拉走了。
- 篡改（Tampering）：请求在传输过程中被改掉。尤其是HTTP明文传输时，中间人随便改参数。你传的是「转账100元」，中间人改成「转账100000元」，后端收到就执行了。
- 信息泄露（Information Disclosure）：接口返回了不该返回的东西。比如错误堆栈、数据库表结构、用户手机号。我曾经见过一个接口，报错时直接把SQL语句吐出来了——攻击者看了就知道你的表结构。
- 权限提升（Elevation of Privilege）：普通用户干了管理员才能干的事。接口适配时，如果权限校验逻辑没映射好，就会出现「A系统的普通用户，通过B系统的接口拿到了管理员权限」。
注意：接口适配中的威胁往往不是单一出现的。数据格式转换时，可能同时存在「篡改」和「信息泄露」；协议适配时，「欺骗」和「拒绝服务」经常结伴而来。做安全设计时，要通盘考虑。
1.3 安全设计的黄金法则
说了这么多威胁，那怎么防？我总结了三条黄金法则。这三条法则，我做了十几年接口，从来没变过。
法则一：默认拒绝（Default Deny）
什么意思？就是接口默认不信任任何请求。只有明确允许的，才放行。
我见过太多接口，白名单没配全，结果「默认允许」了所有IP访问。攻击者扫到端口就能调。正确的做法是：
// 错误示范：默认允许
if (isValidToken(token)) {
// 放行
}
// 正确示范：默认拒绝
if (!isValidToken(token)) {
return 401; // 未授权
}
if (!isInWhitelist(ip)) {
return 403; // 禁止访问
}
// 继续处理业务逻辑我曾经在一个金融项目里，就因为少写了一个「默认拒绝」的逻辑，导致内部接口被外部直接调用。还好发现得早，不然数据就全漏了。
法则二：最小权限（Least Privilege）
接口只给调用方它需要的最小权限。不多给一分。
举个例子：用户查询接口，只需要返回「用户名和头像」，那就别把「手机号、身份证号」也带出来。很多接口设计者图省事，一个接口返回全部字段，结果前端用不到的数据全暴露了。
| 场景 | 最小权限做法 | 常见错误 |
|---|---|---|
| 用户信息查询 | 只返回请求的字段 | 返回全量用户数据 |
| 订单查询 | 只能查自己的订单 | 可以查任意用户的订单 |
| 文件上传 | 限制文件类型和大小 | 允许上传任意文件 |
法则三：纵深防御（Defense in Depth）
别指望一层防护就能挡住所有攻击。要在多个层面设防。
我个人的习惯是，至少设三层：
- 传输层：强制HTTPS，证书双向校验
- 认证层：Token + 签名 + 时间戳，三重校验
- 业务层：参数校验 + 权限校验 + 频率限制
你想想看，就算攻击者绕过了HTTPS，他还有Token这关；就算Token被破解了，还有签名校验；就算签名也被伪造了，业务层的频率限制也能拦住他。三层都突破？那攻击成本已经高到不值得了。
我的经验：这三条法则里，「默认拒绝」是最容易被忽视的。很多团队在接口适配时，只想着「怎么让两个系统通起来」，没想过「哪些请求应该被拒绝」。结果就是，接口通了，安全没了。
1.4 接口适配中的安全设计流程
最后，我分享一下我在项目中实际使用的安全设计流程。这个流程帮我避过不少坑。
这个流程看起来简单，但每一步都有讲究。比如威胁建模，不是画个图就完了。你得真去思考：这个接口暴露了什么数据？谁可能来攻击？攻击路径是什么？
我记得有一次，团队做威胁建模时发现，某个接口虽然加了Token校验，但Token是在URL参数里传的。这意味着Token会被浏览器历史记录、服务器日志记录下来。这就是一个典型的信息泄露风险。后来改成Header传输，问题就解决了。
总结一下：接口安全不是事后补丁，而是从设计阶段就要考虑的事。默认拒绝、最小权限、纵深防御——这三条法则，你记住了，接口安全就成功了一半。