API漏洞的工程解剖：深入剖析OWASP API安全十大风险
内容提要
本文从工程视角剖析OWASP API安全十大风险，指出漏洞多源于架构决策失误而非缺少安全工具。核心观点：授权应在服务层校验资源归属，认证需限流与短令牌，响应须用显式DTO，业务规则由领域层强制，外部接口须验签与契约校验，URL须白名单防SSRF。安全应内建于架构，是工程团队的责任。
延伸解读
授权校验必须下沉到服务层
文章指出，BOLA 和 BFLA 等漏洞的根源在于授权被简化为“是否已认证”，而忽略了“该用户是否拥有此资源”或“是否具备所需角色”。API 网关只能验证令牌有效性，无法判断资源归属和角色要求。因此，所有权检查和角色检查必须在服务层执行，且每次访问具体资源时都要进行，不能只在首次加载或写操作时校验。
显式 DTO 是防止数据泄露的结构性手段
BOPLA 的典型表现是接口直接返回数据库实体，导致 isAdmin、内部评分、欺诈风险等级等敏感字段泄露；或更新操作直接绑定领域实体，允许用户篡改角色等字段。文章强调，每个端点都应有专门设计的响应 DTO，只包含调用方有权获取的字段；请求 DTO 也只接受允许修改的字段，从结构上杜绝越权读写。
业务规则应由领域层强制，而非依赖 UI 隐藏
对于敏感业务流，文章以销售创建为例：若未验证覆盖区域就允许创建销售，业务规则便被绕过。这类规则不能只靠前端隐藏按钮或接口文档约定，而应编码在领域层的工厂方法或值对象中。这样，任何调用方都无法通过 API 创建违反业务规则的实体，从根源上防止业务逻辑被滥用。
外部集成必须验签并校验契约
文章将“不安全地消费 API”和 SSRF 归为信任假设问题。对于第三方回调，必须先验证签名，再按预定义契约校验字段和取值范围，不能直接信任外部数据。对于接受 URL 的接口，必须使用域名白名单并阻止内网地址，且 HTTPS 是强制要求。这些措施应在设计阶段确定，而非事后补救。
Q&A
OWASP API安全十大风险是什么？
OWASP API安全十大风险是由非营利组织OWASP发布的、定期更新的全球生产系统中关键API漏洞列表，基于真实安全事件、渗透测试和漏洞报告编制，包括BOLA、失效认证、BOPLA、无限制资源消耗、BFLA、敏感业务流无限制访问、安全配置错误、不当库存管理、不安全API消费和SSRF。
BOLA漏洞是如何产生的，如何修复？
BOLA产生于授权仅检查用户是否认证，而未验证认证用户是否拥有所请求的资源。修复方法是在服务层进行授权，每次访问特定资源时都检查资源所有权，例如在获取交易前验证账户所有者与当前用户ID匹配。
如何防止API返回过多数据或允许用户修改不应修改的字段？
为每个API端点设计显式的响应DTO，只包含调用者有权接收的字段，避免直接返回领域实体；对于传入请求，使用请求DTO只接受用户允许修改的字段，绝不直接绑定到领域实体。
为什么需要在API网关层实施速率限制？
速率限制必须在API网关层实施，在请求到达服务层之前进行，因为网关可以同时为所有服务处理限流，无需每个服务重新实现。不同端点需要不同限制，例如认证端点严格限制（每IP每5分钟5次），公共读端点中等限制，敏感写操作严格限制。
如何防止用户通过直接调用API绕过UI权限访问管理员功能？
必须在服务层对每个功能检查调用者的角色，而不是依赖UI隐藏按钮。例如在删除用户或获取所有用户前，检查当前用户是否具有管理员角色，否则返回禁止访问错误。
如何防止SSRF攻击？
任何接受URL的API都必须根据允许的域名列表验证URL，要求HTTPS，并显式阻止内部IP地址范围（如127.0.0.1、10.0.0.0/8、169.254.169.254等）。允许列表应作为API规范的一部分，而不是事后添加。
除了OWASP十大风险，还有哪些常见的API工程安全漏洞？
包括：多客户端调用的API未实施域名允许列表；在代码和日志中暴露密钥；微服务之间无网关直接通信；加密算法无组织标准；SQL注入（通过字符串拼接构建查询）。这些都需要通过工程标准来预防。
