为什么API安全需要OWASP Top 10与WAF协同
API的爆发式增长带来了传统Web应用不曾遇到的攻击面：无界面暴露、结构化数据交换、高频自动化调用。OWASP API Top 10是目前最具参考价值的风险清单，但仅有清单远远不够——你必须将每项风险转化为WAF上可执行的检测与阻断逻辑。本文不罗列理论，只讲如何把OWASP风险映射到ModSecurity、Cloudflare WAF、AWS WAF或自研规则引擎中。
API1：对象级授权失效（BOLA）
风险本质
攻击者通过篡改请求中的对象ID（如用户ID、订单号、文档UUID）访问不属于自己的资源。这是API中最普遍的漏洞，因为开发者往往只在页面层做权限检查，而忽略了对每个API端点单独验证。
WAF防护规则制定
- 参数约束规则：对路径参数和JSON体中的ID字段实施正则模式匹配。例如，若预期UUID v4格式，则拒绝非36字符含连字符的输入。
- 上下文绑定规则：无法仅靠WAF完全解决逻辑授权问题，但可强制要求每个请求携带JWT或Session Token，并校验Token中的角色/用户ID与请求资源的关联性——这通常需要WAF与API网关配合，例如在ModSecurity中通过变量
ARGS提取ID并与REQUEST_HEADERS:Authorization解析出的用户身份做交叉验证。 - 速率限制：对同一用户尝试枚举不同ID的行为（如10秒内访问超过5个不同用户资料）触发临时封禁。
API2：用户认证失效
风险本质
弱密码、凭证泄露、会话固定、OAuth流程缺陷等。攻击者利用被盗或猜解的凭证直接获取合法身份。
WAF防护规则制定
- 暴力破解防御：对登录/令牌刷新端点实施严格的速率限制，并追踪源IP+用户名双因子。例如ModSecurity规则：
SecRule IP:rate_login "@gt 10" "phase:2,deny,status:429"。 - 异常请求模式检测：监控Authorization头是否包含异常格式（如多层嵌套的JWT、过期时间戳为1970年），直接拒绝。
- OAuth回调验证：强制校验回调URL的合法性（白名单域名），防止授权码截获。
API3：对象属性级授权失效
风险本质
攻击者通过添加/修改JSON属性（如{"role":"admin","balance":9999}）获得超额权限。常见于API不实施白名单属性过滤，直接反序列化客户端传入的对象。
WAF防护规则制定
- JSON Schema强制校验：在WAF层对POST/PUT请求体执行Schema验证。例如拒绝
role、isAdmin、creditLimit等敏感属性出现在请求中。使用ModSecurity的@validateJsonSchema或自定义lua脚本。 - Mass Assignment检测：对比API文档定义的允许属性集合，任何额外键值对直接返回422并记录告警。
- 请求体大小限制：限制单次请求体大小（如1MB），防止攻击者通过超长JSON枚举属性。
API4：资源消耗与速率限制缺失
风险本质
缺乏速率限制或配额控制，导致API被滥用、资源耗尽（DDoS）、爬取大量数据。
WAF防护规则制定
- 分层速率限制：按API端点、用户、IP、应用API Key设置不同阈值。例如公共查询端点每分钟100次，敏感操作每分钟10次。
- 并发连接控制：对同一IP的并发连接数做上限（如50），超出则排队或拒绝。
- 异常流量模式：检测高频请求中URL路径规律（如递增数字、时间戳），直接加入动态黑名单。
API5：功能级授权失效
风险本质
普通用户执行仅管理员允许的操作（如创建用户、删除数据库）。后端未对每个API端点做角色-权限验证。
WAF防护规则制定
- HTTP方法白名单：对每个端点限制允许的HTTP方法（如
/api/users只允许GET，/api/users/{"id"}只允许PUT）。任何DELETE、PATCH等未允许方法直接拒绝。 - 敏感路径隐藏：在WAF层面将管理端点的URL前缀（如
/admin/、/internal/）仅允许内部VPN IP访问，或要求特定的Header（如X-Role: admin）并由WAF验证签名。 - 参数风险标识：对参数名中包含
delete、drop、exec等关键词进行拦截。
API6：批量分配与过度数据暴露
风险本质
API返回了比客户端需要更多的字段（如用户密码哈希、内部配置），攻击者通过分析响应发现攻击面。
WAF防护规则制定
- 响应字段白名单：在WAF反向代理层配置响应体过滤，仅保留原始API文档中声明的字段。例如Cloudflare Workers可以解析JSON并删除未列出的键。
- 敏感数据模式识别：检测响应体中是否包含信用卡号（Luhn算法）、密码密钥（如
"password":"..."）、AWS密钥等，匹配则触发告警并脱敏或阻断。
API7：安全配置错误
风险本质
默认凭证、不安全的CORS、未禁用HTTP方法、错误消息堆栈泄露、未打补丁的组件等。
WAF防护规则制定
- HTTP头加固：在WAF层统一添加
X-Frame-Options: DENY、Strict-Transport-Security等安全头。移除Server、X-Powered-By等泄漏信息的头。 - CORS严格策略：拒绝
Access-Control-Allow-Origin: *的响应，仅允许配置的白名单域名。 - 错误信息过滤：对响应体中的stack trace、SQL语句模式进行正则替换为通用错误消息。
API8：注入攻击
风险本质
SQL、NoSQL、OS命令、LDAP注入等。由于API常接收结构化输入（JSON/XML），注入面甚至更广。
WAF防护规则制定
- 请求体内容扫描：对所有POST/PUT请求体应用注入检测规则（如OWASP CRS中的SQLi、XSS规则集）。注意需支持JSON/XML/GraphQL多格式解析。
- 特殊字符过滤：对字符串类型的参数，去除或编码单引号、分号、双横线、
1=1等注入特征。但需注意不要破坏业务功能（如段落包含标点），可通过白名单允许字段。 - NoSQL注入检测：对MongoDB类API，检测
$gt、$ne、$regex等操作符是否出现在参数中，并验证是否属于预期使用场景。
API9：资产管理不当
风险本质
老版本API未下线、测试/调试端点暴露、API文档泄露、未使用的端点仍可访问。
WAF防护规则制定
- 版本路由隐藏：在WAF层面仅允许
/api/v2/访问，对/api/v1/、/api/test/、/api/old/返回404或重定向至当前版本。 - 端点发现防护：对不存在的URL路径返回通用404，不提示是否存在该资源（如只返回
{"error":"Not Found"}，不区分“路径不存在”与“资源不存在”）。 - Swagger/OpenAPI暴露控制：限制
/swagger.json、/api-docs等文档路径仅允许管理CIDR或通过Token访问。
API10：日志与监控不足
风险本质
攻击行为未被记录，导致无法溯源、延迟响应、合规问题。WAF自身日志也常被忽略。
WAF防护规则制定
- 详细审计日志：确保WAF记录每个被拦截请求的完整元数据（时间、源IP、User-Agent、请求体摘要、触犯规则ID）。
- 告警聚合与阈值：当同一规则在短时间内触发超过阈值（如5分钟50次），自动升级为高优先级告警并通过Webhook发送至SIEM。
- 误报反馈机制：建立白名单模板，将业务确认的误报请求加入排除规则，同时记录原始事件供后续优化。
结语：从静态规则到自适应防护
WAF规则不是一次性设置即可高枕无忧。API的业务逻辑变化快、攻击手段演进快。建议团队每两周基于OWASP API Top 10更新版本重新评审规则集，并结合机器学习异常检测来弥补模式匹配的盲区。真正的API安全，在于将风险清单转化为WAF上可验证、可测试、可回滚的策略代码。
延伸阅读