一、为什么 API 成为新的攻击重点
随着前后端分离、小程序、APP 的普及，API 接口承担了绝大部分业务逻辑。这带来了攻击面的转移：
- 过去攻击者打的是页面和表单，现在打的是接口；
- 接口返回的是结构化数据，抓取和分析成本更低；
- 很多接口没有做严格的权限校验；
- 接口数量多、迭代快，容易出现安全盲区。
更关键的是：接口攻击的「业务收益」往往更高——比如批量调用短信接口造成真金白银的损失，或通过参数篡改低价下单。
二、API 的四类风险与 WAF 防护能力
1. 注入类攻击——WAF 可有效防护
本质上和 Web 攻击一样：接口参数里拼接 SQL、命令、模板表达式等。WAF 的规则引擎同样适用，防护效果稳定。
2. 接口滥用——WAF 可有效防护
这是 WAF 对 API 最有价值的能力之一。典型场景：
- 短信/邮件接口被刷——每次调用产生费用，攻击者可造成直接经济损失；
- 验证码接口被爆破——暴力破解验证码；
- 查询接口被高频调用——耗尽数据库资源；
- 注册接口被批量调用——制造垃圾账号。
WAF 通过频率限制可以有效抑制。关键是对不同接口设置差异化阈值。
3. 参数篡改——WAF 只能部分防护
这类攻击指修改请求参数来获取不当利益：
| 攻击手法 | 示例 | WAF 能力 |
|---|---|---|
| 价格篡改 | 把订单金额改成 0.01 | ❌ 请求格式完全合法，无法判断 |
| 数量篡改 | 把购买数量改成负数 | ⚠️ 可用规则拦截明显异常值 |
| 越权访问 | 把 order_id 改成别人的 | ❌ 需代码层鉴权 |
| 优惠券叠加 | 重复使用同一张券 | ❌ 属业务逻辑漏洞 |
可以看出，纯业务逻辑类的问题 WAF 无从判断——因为请求本身完全合法。但一些「明显反常」的值（如负数量）可以用自定义规则拦截。
4. 未授权访问——WAF 无法解决
如果接口本身没有做鉴权，或者鉴权可以被绕过，WAF 拦不住。这必须靠代码层的认证授权机制解决。
三、WAF 的 API 防护配置要点
① 敏感接口单独设阈值
这是最重要的一条。以下接口必须设置严格的频率限制：
| 接口类型 | 建议策略 |
|---|---|
| 短信/邮件发送 | 按手机号 + IP 双重限频，如每手机号 1 分钟 1 次 |
| 登录接口 | 按账号 + IP 限频，配合验证码 |
| 验证码校验 | 限制尝试次数，如连续 5 次失败锁定 |
| 支付相关 | 低频 + 异常检测 |
| 数据导出 | 严格限频，防止批量爬取 |
② 参数格式校验
用自定义规则限制参数的格式：
- ID 类参数限定为数字或 UUID 格式；
- 限制参数长度，防止超长字符串攻击；
- 拒绝包含特殊字符的参数（除非业务需要）；
- 校验参数数量，拒绝多余参数。
③ 限制请求方法
只放行业务实际需要的方法。比如查询接口只允许 GET，提交接口只允许 POST，把不需要的 PUT、DELETE、OPTIONS 等直接拒绝——这能减少一部分攻击面。
④ 监控异常调用模式
除了频率，还要关注调用模式的异常：
- 短时间内遍历大量连续的 ID（典型的拖库行为）；
- 同一个 Token 从多个 IP 调用（凭证泄露）；
- 异常的用户代理或 Referer。
四、代码层必须做的事
WAF 做流量层防护，以下工作必须在代码层完成：
- 每个接口都要鉴权——不要假设「前端不会调用到」；
- 服务端校验业务规则——价格、数量、权限等必须服务端校验，不能信任前端传值；
- 越权防护——每次数据访问都要校验「这条数据是否属于当前用户」；
- 参数化查询——防止注入；
- 接口版本管理——老接口下线要彻底，避免遗留未授权的入口。
五、小结
WAF 对 API 的防护能力有明确边界：注入类攻击和接口滥用可以高效防护，参数篡改只能部分覆盖，未授权访问无法解决。因此 API 安全必须「WAF + 代码」双管齐下——WAF 挡住流量层的批量攻击，代码层解决逻辑与权限问题。
如果你的站点正被恶意爬虫、CC 攻击困扰，或需要一套开箱即用的 Web 应用防护，可以了解百度云防护 Web 应用防火墙（专业版 299 元/月，年付 2399 元，可联系主机吧客服购买）——支持自定义访问策略、URI 频率限制、BOT 防护、威胁情报与 API 防护，无需改动源站代码，改 DNS 即可接入。包年包月计费，流量峰值买多少防多少，无后付费陷阱。
