API安全性已经成为企业组织的一个关键性业务发展问题，而非仅仅是信息安全的问题，很多企业由于担心API安全问题，而不得不推迟新业务系统的应用。由于当前的技术工具和安全流程无法跟上API安全发展的步伐。组织必须寻找更有效的API安全防护措施，在API应用生命周期的每个阶段进行安全性验证和保护。

2023年API安全事件

API安全公司FireTail认为，2023年将成为API泄露事件创纪录的一年。根据该公司的监测，今年以来已有超过5亿条数据信息因为易受攻击的API应用而导致了泄露，其中较为严重的API安全事件包括：

• 2023年1月，丰田（Toyota）、梅赛德斯（Mercedes）、宝马（BMW）和其他十几个汽车品牌曝出API相关漏洞。远程信息处理系统中的API漏洞不仅仅暴露了客户数据，还允许恶意行为者远程实现按喇叭、闪烁灯、远程跟踪、开关车门、启停车辆等操作； 
• 同月，T-Mobile公开承认，黑客利用一个API漏洞窃取了3700万客户的数据；
• 2023年2月，Trustwave研究人员发现，Finsify公司的Money Lover个人理财应用暴露了其500多万用户的电子邮件地址和数字钱包账号；
• 2023年3月，CISA发布了一份关于Nexx车库门控制器和智能报警器的安全公告，在超过40,000台设备中发现了存在多个API应用漏洞，攻击者可以利用这些漏洞窃取个人信息，如物理地址、打开车库门和关闭警报；
• 2023年6月，Patchstack研究人员报告称，WooCommerce公司最受欢迎的WordPress支付插件WooCommerce Stripe Gateway中存在一个严重API漏洞，允许未经身份验证的用户查看用户订单的敏感数据，包括电子邮件和完整地址。该漏洞累计影响了50万以上用户的个人隐私安全；
• 同样在6月，Eaton Works的一名研究人员入侵了本田汽车电子商务平台，通过利用API接口漏洞，他可以重置任何账户的密码，并获得完整的客户信息、经销商信息、付款密钥和内部财务报告。该事件导致了近40,000条车主记录暴露；
• 2023年7月，为超过18万家企业提供云“目录即服务”（directory-as-a-service）的软件服务商JumpCloud公司，因API相关漏洞而全部更改了其API应用密钥。

API应用安全挑战

根据Enterprise Strategy Group公司对超过400家企业的调研统计，有超过92%的组织在过去12个月里至少经历了一次与API相关的安全事件，而导致API应用安全事件日益普遍的原因主要包括：API生态系统的规模、应用复杂性和快速变化的本质。

研究人员发现，面对API应用快速增长，企业组织最担忧的问题是缺少对API访问行为的有效认证和控制。在不久前刚刚更新的2023年度“OWASP TOP 10 API安全风险”清单中，和身份验证和授权相关的安全风险有四个。而FireTail API数据泄露跟踪报告的相关数据也显示，在今年所监测到的12起公共API应用数据泄露事件中，每一起都涉及至少一个身份验证或授权方面的安全漏洞。

API安全应用的另一个重要挑战是如何识别其中的关键数据以及如何监控这些数据在API生态系统中安全地流动。为了保证安全性，企业组织需要弄清楚他们最敏感的数据是什么、在哪里、谁可以访问，并根据这些信息来设计API的安全性。不幸的是，很多公司需要手动操作来完成以上工作，这是一个缓慢且易出错的过程，也无法真正理解API与其所连接的数据之间的逻辑关系。

缺乏可见性也是API安全应用的主要挑战。毕竟，我们无法保护自己看不见的东西。在企业中，除了API应用的开发者，很少有人会意识到这些API的存在，这使得大量的API缺少维护，并经常容易被忽略。当组织缺乏适当的API可见性、治理机制和生命周期策略时，僵尸、影子和幽灵等可怕的API威胁就会出现。

最后，企业对API应用安全的保障能力存在不足。调查数据显示，尽管有74%的受访企业表示他们已经部署了API安全工具，但事实上并未形成有效的防护能力。很多传统API管理工具，缺乏解决API特有漏洞所需的具体功能，也无法提供检测特定API攻击（比如撞库攻击和蛮力破解）所需的可见性。

API安全性自查清单

企业需要寻求更加有效API安全防护策略和方法，以减少API安全治理的复杂性和管理成本。

参考2023年度“OWASP TOP 10 API安全风险”清单，安全研究人员总结梳理了一份易于遵循的API安全性检查清单，通过全面的API安全风险检查，企业可以有效提升API应用的安全性。

OWASP - A1 ：对象级授权

1. 验证是否使用用户策略和层次结构实现授权检查； 
2. 验证API是否需要依赖于从客户端发送的身份ID，API应用应该检查会话中存储对象的ID； 
3. 验证服务器配置是否按照所使用的应用服务器和框架的建议进行了加固； 
4. 验证API是否实现了在每次客户端请求访问数据库时检查授权； 
5. 验证API没有使用随机猜测ID（UUID）。 

OWASP - A2：破损的认证

1. 验证是否全面认证所有API； 
2. 验证密码重置API和一次性链接是否允许用户一起进行身份验证，并受到严格保护； 
3. 验证API是否实现标准的身份验证，令牌生成，密码存储和多因素身份验证； 
4. 验证API是否使用了短期访问令牌； 
5. 验证API是否使用了严格的速率限制身份验证，并实现锁定策略和弱密码检查。

OWASP - A3：过度的数据暴露

1. 验证API是否依赖于客户端来过滤数据； 
2. 验证API响应性，并根据API使用者的实际需要调整响应； 
3. 验证API规范性，定义所有请求和响应的模式； 
4. 验证错误API响应是否已经明确定义； 
5. 验证所有敏感或PII信息的使用是否有明确的理由； 
6. 验证API强制响应检查措施，以防止意外的数据和异常泄漏。

OWASP - A4：缺乏资源和速率限制

1. 验证是否根据API方法、客户端和地址配置了速率限制； 
2. 验证有效载荷限制是否已配置； 
3. 在执行速率限制时验证压缩比；
4. 验证计算/容器资源上下文中的速率限制。 

OWASP - A5：无效的功能级授权

1. 验证默认情况下是否能够拒绝所有访问； 
2. 验证API是否依赖于应用程序来强制管理访问； 
3. 验证所有不需要的功能是否都被禁用； 
4. 验证计算/容器资源内容中的速率限制是否有效； 
5. 确保仅根据特定角色授予角色； 
6. 验证授权策略是否在API中正确实现。

OWASP - A6：批量分配

1. 验证API是否自动绑定传入数据和内部对象； 
2. 验证API是否显示定义组织期望的所有参数和有效负载； 
3. 验证API在设计时是否精确定义了访问请求中接受的模式、类型和模式，并在运行时强制执行它们。

OWASP - A7：安全配置错误

1. 验证API实现是否可重复，并且加固和修复活动已纳入开发过程；
2. 验证API生态系统是否具有自动定位配置缺陷的过程； 
3. 验证平台是否在所有API中禁用了不必要的功能； 
4. 验证API安全系统是否可以限制管理访问； 
5. 验证所有的输出是否安全，包括错误的输入； 
6. 验证授权策略是否在API中正确实现。

OWASP - A8：请求伪造  

1. 验证API对各类消费者的信任机制是否正确，即使是对内部员工的； 
2. 验证API是否严格定义所有输入数据：模式、类型、字符串模式，并在运行时强制执行； 
3. 验证API是否可以对所有传入数据进行验证、过滤和阻断； 
4. 验证API是否定义、限制和执行API输出，以防止数据泄漏。

OWASP - A9：资产管理不当

1. 验证平台能否限制访问任何不应公开的内容；  
2. 验证API应用架构是否具备额外的外部安全控制，如API防火墙； 
3. 验证一个API应用进程是否被有效地管理； 
4. 验证架构是否实现严格的API身份验证、重定向等。

OWASP - A10：日志记录和监控不足

1. 验证API日志的完整性和准确性； 
2. 验证日志格式是否可以被其他工具有效使用； 
3. 验证API应用管理平台是否对敏感日志进行了有效保护； 
4. 验证API应用平台是否包含足够的详细信息以识别攻击者； 
5. 验证平台与SIEM等其他安全工具是否可以协同、集成。

参考链接：https://gbhackers.com/api-security-checklist/