随着人工智能的发展，数据安全和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 ：对象级授权

验证是否使用用户策略和层次结构实现授权检查；

验证 API 是否需要依赖于从客户端发送的身份 ID，API 应用应该检查会话中存储对象的 ID；

验证服务器配置是否按照所使用的应用服务器和框架的建议进行了加固；

验证 API 是否实现了在每次客户端请求访问数据库时检查授权；

验证 API 没有使用随机猜测 ID（UUID）。

OWASP - A2：破损的认证

验证是否全面认证所有 API；

验证密码重置 API 和一次性链接是否允许用户一起进行身份验证，并受到严格保护；

验证 API 是否实现标准的身份验证，令牌生成，密码存储和多因素身份验证；

验证 API 是否使用了短期访问令牌；

验证 API 是否使用了严格的速率限制身份验证，并实现锁定策略和弱密码检查。

OWASP - A3：过度的数据暴露

验证 API 是否依赖于客户端来过滤数据；

验证 API 响应性，并根据 API 使用者的实际需要调整响应；

验证 API 规范性，定义所有请求和响应的模式；

验证错误 API 响应是否已经明确定义；

验证所有敏感或 PII 信息的使用是否有明确的理由；

验证 API 强制响应检查措施，以防止意外的数据和异常泄漏。

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

验证是否根据 API 方法、客户端和地址配置了速率限制；

验证有效载荷限制是否已配置；

在执行速率限制时验证压缩比；

验证计算 / 容器资源上下文中的速率限制。

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

验证默认情况下是否能够拒绝所有访问；

验证 API 是否依赖于应用程序来强制管理访问；

验证所有不需要的功能是否都被禁用；

验证计算 / 容器资源内容中的速率限制是否有效；

确保仅根据特定角色授予角色；

验证授权策略是否在 API 中正确实现。

OWASP - A6：批量分配

验证 API 是否自动绑定传入数据和内部对象；

验证 API 是否显示定义组织期望的所有参数和有效负载；

验证 API 在设计时是否精确定义了访问请求中接受的模式、类型和模式，并在运行时强制执行它们。

OWASP - A7：安全配置错误

验证 API 实现是否可重复，并且加固和修复活动已纳入开发过程；

验证 API 生态系统是否具有自动定位配置缺陷的过程；

验证平台是否在所有 API 中禁用了不必要的功能；

验证 API 安全系统是否可以限制管理访问；

验证所有的输出是否安全，包括错误的输入；

验证授权策略是否在 API 中正确实现。

OWASP - A8：请求伪造  

验证 API 对各类消费者的信任机制是否正确，即使是对内部员工的；

验证 API 是否严格定义所有输入数据：模式、类型、字符串模式，并在运行时强制执行；

验证 API 是否可以对所有传入数据进行验证、过滤和阻断；

验证 API 是否定义、限制和执行 API 输出，以防止数据泄漏。

OWASP - A9：资产管理不当

验证平台能否限制访问任何不应公开的内容；  

验证 API 应用架构是否具备额外的外部安全控制，如 API 防火墙；

验证一个 API 应用进程是否被有效地管理；

验证架构是否实现严格的 API 身份验证、重定向等。

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

验证 API 日志的完整性和准确性；

验证日志格式是否可以被其他工具有效使用；

验证 API 应用管理平台是否对敏感日志进行了有效保护；

验证 API 应用平台是否包含足够的详细信息以识别攻击者；

验证平台与 SIEM 等其他安全工具是否可以协同、集成。

除以上策略外，我们要让api服务器远离威胁还要配备专业的高防产品，防火墙和应急策略，这样才能最大限度的减小API安全威胁。