接口的风险和页面不一样

页面的访问大多由人触发，接口的调用则由程序发起，两者面临的威胁并不相同。接口一旦被公开，别人可以照着格式构造请求，反复调用，速度远高于人工。更麻烦的是，很多接口设计时只考虑了功能，没考虑被反复调用会产生什么后果。

常见的后果有几类：短信和邮件被大量发出，直接产生费用；数据被批量拉取，内容优势消失；业务资源被占满，正常用户无法使用；以及通过大量请求试探出系统的行为规律。

所以接口的安全要在设计阶段就当成一部分，而不是上线之后再补。补的时候往往已经形成了固定的调用方式，改动代价高得多。

身份与权限要核对到数据层面

接口的身份校验不能停在有没有登录。很多问题的根源是只确认了调用者的身份，却没有确认它有没有权限操作这一条具体数据。用一个合法账号去改别人的订单，请求本身完全合法，只有在数据层面做归属判断才能发现。

对外的接口建议使用独立的凭据，并配合签名。签名把请求内容和时间一起纳入计算，篡改参数或者重放旧请求都会失败。这比单纯依赖一个固定的密钥要可靠。

权限的范围也要收窄。接口只返回必要字段，能查询的范围限定在自己的数据里，避免一个接口被拿去做全量拉取。

防刷的几种手段

频率限制是最直接的一层。按调用方统计单位时间内的请求数量，超过就拒绝或者排队。对涉及费用和资源的接口，阈值要单独设置得更严。

对需要人工操作的场景，可以引入验证环节，比如图形验证、行为校验。它的成本是体验，适合放在被刷得最严重的那些接口上。

请求的一次性校验也很有用。同一次提交只能生效一次，重复提交直接返回之前的处理结果，能挡住相当一部分自动化重复调用。

对异常调用要有感知。调用量的突然上升、来源分布的变化、失败率的异常，这些都值得配置告警，而不是等到费用账单出来才发现。

上线之后怎么维护

把接口清单维护起来，写清楚每个接口的用途、调用方和权限范围。新增接口时同步更新，避免出现没人知道的对外开放入口。

定期做一次针对接口的测试，用自己的账号去调用不该有权限的数据，看是否被拒绝。这类测试能发现大部分权限层面的问题。

版本变更时注意旧接口的处置。很多风险来自早已废弃却仍然可以调用的老版本，它们不在当前的维护范围内，却依然通着。

把接口的防护和业务方沟通清楚。哪些限制是为了控制成本，哪些是为了保护数据，说清楚了，遇到调整时也更容易达成一致。

把防护做成开发流程的一部分

接口上线前走一遍检查，比上线后补救省事。检查的内容可以固定下来：身份校验方式、权限判断到哪个层面、频率限制有没有配置、返回字段是否最小化。把这几项列成清单，开发自己就能先过一遍。

团队里可以约定一个简单的评审环节，由另一位同事看一下接口的权限判断和返回内容。这类评审不需要很长时间，却能发现很多只顾功能时忽略的问题。

接口文档里也要写清楚权限要求。写清楚谁能调用、能拿到哪些数据，后续做测试和排查时就有依据。

异常流量的具体表现

被刷的接口通常有几个明显的表现：调用量在某个时间点陡增、单次请求的参数高度雷同、失败率异常升高，或者某个来源的调用集中在很短的时间内。把这些模式配置成告警，比事后从账单里发现问题要早得多。

观察一段时间之后，可以给每个接口建立一个大致的调用量范围。超出范围不一定代表被攻击，但值得看一眼。

告警的处理要有明确的负责人和动作。收到告警却不知道该做什么，和没有告警差别不大。

涉及费用的接口建议单独设置更严格的告警线，它们的成本最直接。

记录与回溯

把接口的调用记录保留一段时间，出问题时能回看是哪一类请求先出现的。记录里至少留下时间、来源和请求的参数类型，不需要内容本身，也能判断出问题的来路。保留期限按业务需要设定，不必无限期保存，到期清理即可。

有了这些记录，判断拦截规则是否合理也有了依据，比凭印象调整可靠得多。