本文目录导读：
Web应用防火墙（WAF）能够在一定程度上防护API安全，但它不能完全覆盖API特有的所有风险，WAF是API安全防护的重要防线之一，但不是全部。
为了帮助你更清晰地理解，下面分别列出WAF能做什么、不能做什么,以及如何更好地保护API。
WAF能防护的API安全风险（传统Web攻击）
WAF设计之初主要用于防护Web应用，而API本质上是Web应用的延伸，因此WAF可以拦截针对API的传统Web攻击，
- SQL注入（SQLi）：攻击者在API请求参数中注入恶意SQL代码。
- 跨站脚本攻击（XSS）：通过API返回恶意脚本（尽管API通常不渲染页面，但若被其他应用调用仍有风险）。
- 命令注入：在API输入中插入操作系统命令。
- 跨站请求伪造（CSRF）：利用合法用户的会话发起恶意API请求。
- 路径遍历：攻击者试图访问API服务器上未授权的文件或目录。
- 协议攻击（如HTTP慢速攻击）：消耗服务器资源。
核心能力：
- 基于签名（已知攻击模式）和正则表达式进行检测。
- 基于请求速率进行CC攻击防护（一定程度上能防DDoS）。
- 对请求体、请求头、URL进行内容检查。
WAF难以防护的API特有风险（核心短板）
API安全面临很多WAF难以检测甚至完全无法检测的威胁，原因是WAF不理解业务逻辑和API的语义。
| 风险类型 | 具体例子 | WAF为何难防护 |
|---|---|---|
| 业务逻辑漏洞 | - 越权访问：用户A通过API查看用户B的订单（IDOR）。 - 批量数据泄露：调用 /users/export API导出全量用户数据。- 交易篡改：修改购物车API中的商品价格（-1元）。 |
WAF只能看到请求格式是否正确，无法判断一个用户是否“应该”访问另一个用户的数据，这属于业务逻辑层，需要上下文感知。 |
| API滥用 | - 撞库/凭证填充：用泄露的密码库大量尝试登录API。 - 爬虫：用自动化脚本抓取API返回的商品价格、用户信息。 - API滥用（如过度调用免费额度）。 |
虽然WAF有速率限制，但无法区分“正常用户”和“非正常用户”（如合法但恶意的爬虫），且很难识别低频但持续的攻击。 |
| API结构攻击 | - 参数污染：恶意构造id[]=1&id[]=2绕过简单校验。- 内容类型混淆：将JSON请求改为XML或Form，利用解析差异。 - HTTP方法滥用：对只读API发送 DELETE请求。 |
需要深入理解API的OpenAPI/Swagger规范，WAF通常不具备。 |
| 未授权访问 | - 暴露了内部测试API（如/v2/internal/debug）。- 使用了过时的、未打补丁的API版本（如 /v1/legacy）。 |
WAF只能拦截已知的漏洞利用，无法主动发现未授权的API端点。 |
| JWT/Token伪造 | 攻击者篡改JWT中的payload，或使用过期的Token。 | WAF通常不解析JWT签名和有效期（除非配置复杂的规则），这是API网关或认证服务器的工作。 |
| 零日API漏洞 | 新型的API攻击手法（如GraphQL注入、JSON解析漏洞）。 | 传统WAF依赖已知签名，难以防御未知的攻击。 |
WAF是必需品，但不是解决方案
| 防护能力 | 等级 | 说明 |
|---|---|---|
| 传统Web攻击（SQLi、XSS等） | ✅ 强 | WAF表现良好，是基础防线。 |
| DDoS/CC攻击 | ✅ 中等 | 能应对应用层攻击，但需与CDN、DDoS清洗配合。 |
| 业务逻辑漏洞（越权、篡改） | ❌ 弱 | 基本无效，需要业务审计。 |
| API滥用（撞库、爬虫） | ❌ 弱 | 需要专业Bot管理工具。 |
| API发现与影子API | ❌ 无 | 需要API安全扫描工具。 |
| API数据泄露（敏感数据暴露） | ✅ 中等 | 可通过配置规则（如返回数据中的身份证号），但无法发现数据过度暴露。 |
最佳实践：如何用组合拳保护API安全？
建议采用 “分层防护” 策略,WAF只是其中一层。
-
第一层：API网关 / 反向代理
- 职责：认证、授权、限流、TLS终止、请求路由、格式校验。
- 工具：Kong、Apigee、AWS API Gateway、Nginx + Lua。
- 核心：结构验证（严格匹配OpenAPI规范）、身份验证（OAuth 2.0、JWT验证）。
-
第二层：WAF（Web应用防火墙）
- 职责：传统Web攻击防护、基础DDoS防护、恶意IP封禁、通用漏洞规则。
- 工具：Cloudflare WAF、AWS WAF、Azure WAF、F5、开源ModSecurity。
- 配置：开启针对API的攻击规则集（如OWASP API Security Top 10规则）,设置速率限制。
-
第三层：API安全检测平台（WAAP / API Security）
- 职责：
- 发现：自动发现所有API端点（包括影子API、僵尸API）。
- 行为分析：通过机器学习建立API正常调用基线，检测异常行为（如异常的数据量爬取、间歇性攻击）。
- 业务逻辑检测：识别越权访问（通过对比用户A和用户B的请求）、参数篡改。
- 敏感数据泄露防护：检测响应中是否返回了信用卡号、密钥等。
- 工具：Salt Security、Noname Security、Akamai API Security、Cloudflare API Shield、开源项目如Talisman。
- 职责：
-
第四层：应用层加固（开发侧）
- 职责：从代码层面避免漏洞。
- 措施：
- 强制输入验证：白名单校验所有参数。
- 严格授权：每次API调用都必须验证“用户是否拥有该资源的访问权限”（如检查
user_id是否等于当前会话用户）。 - 敏感数据脱敏：响应中不要返回不必要的敏感字段。
- 使用安全的API框架：自动处理参数绑定、SQL注入防护。
- WAF能防：SQL注入、XSS、路径遍历等通用Web漏洞。
- WAF不能防：业务逻辑漏洞（如越权、篡改参数）、API滥用（复杂爬虫、撞库）、未发现的影子API、零日API攻击。
建议：如果你的API仅处理公开数据且攻击面较小，WAF可能足够，但对于涉及用户认证、交易、敏感数据的API，强烈建议在WAF之上，部署专门针对API安全的检测平台（WAAP或API Security）,并配合严格的API网关和应用层安全审计。
