API 安全概述#

凌晨三点，某电商平台的API监控突然告警：某接口的调用量在5分钟内飙升了100倍，同时伴随着大量的登录失败和异常订单创建。经过紧急排查，发现是攻击者利用该平台的搜索API，通过构造大量恶意请求，结合缓存穿透，成功打垮了整站服务。

这不是孤例。根据非营利安全组织 OWASP 的统计，API 安全事件在过去三年增长了 300%，而其中一个重要原因是：大多数企业将安全重心放在了传统的 Web 应用层面，却忽视了 API 本身也是主要的攻击面。

#为什么 API 成了主要攻击面

API 的崛起是互联网架构演进的结果。移动应用、SaaS 服务、微服务架构、物联网设备——这些场景都依赖 API 作为数据交换的核心手段。一个典型的互联网公司，对外暴露的 API 数量往往是其网站页面数量的 10 倍甚至更多。

但 API 的开放性也带来了新的问题：

1. 攻击面更大。传统 Web 应用通过表单和链接与用户交互，入口相对固定。而 API 的每个端点、每个参数、每种 HTTP 方法，都可能是潜在的攻击入口。一个 /api/v1/users/:id 端点，如果缺少权限校验，攻击者只需修改 :id 参数，就能访问任意用户的数据。

2. 协议更底层。API 直接暴露业务逻辑和数据结构，不像 Web 页面有 HTML/CSS 的「视觉屏障」。攻击者可以更直观地看到请求参数，更容易发现参数类型错误、边界条件处理不当等漏洞。

3. 认证机制复杂化。传统 Web 应用依赖 Session-Cookie 机制，而 API 需要支持 API Key、OAuth Token、JWT、自定义签名等多种认证方式。认证实现的任何疏漏，都可能导致认证绕过。

4. 自动化攻击更容易。Web 页面的爬虫需要解析 HTML、执行 JS、模拟用户行为，而 API 返回的是结构化的 JSON 数据，任何工具都能轻易地批量采集。

#API 攻击的常见类型

API 攻击与传统 Web 攻击有重叠，但也有很多 API 特有的攻击手段：

#对象级授权失效（IDOR）

这是 API 攻击中最常见的类型。攻击者通过修改请求中的资源标识符（如用户 ID、订单 ID），访问本不属于他的资源。

# 正常请求：获取自己的订单
GET /api/v1/orders/12345
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

# 恶意请求：修改订单ID，尝试获取他人订单
GET /api/v1/orders/12346
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

如果服务端未校验当前用户与资源的所有权关系，12346 对应的订单数据就会被泄露。

#批量查询攻击

某些 API 功能本身是合理的，但如果不加限制地被批量调用，就会变成 DoS 攻击。例如，一个允许按邮箱前缀搜索用户的接口，如果被攻击者用来枚举整个邮箱系统的用户，结果将是灾难性的。

#参数污染与注入

API 的灵活性使得它接受各种参数格式：Query String、JSON Body、Path Parameter、Header。攻击者可以通过参数污染绕过输入校验，通过 SQL 注入、NoSQL 注入、命令注入等手段获取未授权数据或执行非法操作。

#认证与会话攻击

API 的认证机制是攻击者的重点目标：弱密码策略、Token 泄露、认证绕过、Token 伪造、会话固定攻击、密码爆破等。

#业务逻辑攻击

这类攻击不依赖技术漏洞，而是利用业务流程设计的缺陷。例如，电商系统中的「1 分钱购买商品」漏洞、社交平台的「刷赞」机制漏洞，都属于业务逻辑攻击。

#API 安全与传统 Web 安全的区别

两者最大的区别在于：传统 Web 安全假设攻击者「看到」的东西是有限的（他只能通过表单提交数据），而 API 安全假设攻击者「完全了解」系统接口（他可以直接构造任意请求）。这个假设的变化，导致了防护策略的根本转变——在 API 安全的场景下，你不能依赖「攻击者不知道」来保护系统，而必须假设「攻击者什么都知道」，所以每一层保护都需要做到位。

#OWASP API Security Top 10 概览

OWASP 在 2023 年发布了最新的 API Security Top 10，将 API 特有的安全风险做了系统性的分类：

mindmap
  root((API 安全风险))
    API1:2023 失效的对象级授权
      攻击者通过修改ID访问他人资源
    API2:2023 失效的身份认证
      Token泄露、弱密码、认证绕过
    API3:2023 失效的对象属性级授权
      过度暴露字段、白名单缺失
    API4:2023 不受限的资源消耗
      无限流、DoS、暴力破解
    API5:2023 失效的功能级授权
      垂直越权、管理端点暴露
    API6:2023 不受限的敏感业务访问
      SSRF、内部服务探测
    API7:2023 错误的配置
      CORS错误、调试模式开启
    API8:2023 注入
      SQL注入、NoSQL注入、命令注入
    API9:2023 不当的资产管理
      旧版本API未维护、文档泄露
    API10:2023 不充分的日志与监控
      攻击行为未被检测

这份列表不是简单的漏洞堆砌，而是基于真实安全事件和渗透测试结果总结的实战经验。后续章节会逐一深入讲解每个风险的具体防御策略。

#API 安全的整体策略

面对 API 安全挑战，企业需要建立多层防护体系：

第一层：入口控制。API 网关负责统一认证、TLS 加密、限流、协议转换。网关是 API 的「门卫」，需要在流量进入业务层之前完成初步过滤。

第二层：认证与授权。每个 API 调用都必须经过身份验证（确认「你是谁」）和权限检查（确认「你能做什么」）。JWT、OAuth2、API Key 是常见的认证手段；RBAC、ABAC 是常见的授权模型。

第三层：输入验证。所有输入参数都必须经过严格校验：类型检查、格式验证、范围限制、白名单过滤。输入验证是防止注入攻击的根本手段。

第四层：业务风控。在技术安全之外，还需要业务层面的风险控制：同 IP 的高频访问、异常时间段的敏感操作、批量化的数据访问，都是业务风控的关注点。

第五层：监控与响应。安全不是静态的，需要持续的监控和快速的响应能力。异常行为的实时告警、安全事件的自动化响应，是安全运营的核心能力。

#思考题

问题 1：为什么 API 的「IDOR」漏洞（失效的对象级授权）比传统 Web 应用更常见？

问题 2：API 安全与微服务安全有何联系和区别？

问题 3：为什么 API 安全需要「零信任」理念？