API安全应用场景系列之二：API 业务清单梳理及验证

在第二期我们分享了“API 业务发现”这一话题，旨在帮助安全团队实时了解网络环境中存在的 API 对象及其属性，内容等信息，从安全团队的视角掌控所有 API 访问的状态；读者可能会想，然后呢？先暂且不表，我们后续分解。

我们先来看几个当前 API 应用环境中存在的挑战：

随着互联网上业务种类的不断增加，出现了以 API 为中心的 API 经济生态。如近年在金融行业广泛兴起的开放银行,其基础就是基于 API  实现整个生态的布局，那么潜在的 API 安全风险就会越大。在这种大背景下，企业安全团队基于什么有效的 API 信息来实现业务的安全保护，抵御潜在的安全风险呢？

经常出现开发过程中对应的 API 接口说明文档不全或者缺失的情况。在OWASP API Top 10 风险的 A9 中明确阐述了 API 接口清单的重要性。

没有标准的 API 接口规范描述文件，安全团队无法得知该 API 业务到底存在哪些真实的 API 对象，提交的 API 数据请求是否规范，是否包含敏感数据等，从而无法定制合适的安全防护策略；

●在关于个人信息安全的国家推荐性标准GB/T 35273-2020《信息安全技术个人信息安全规范》中，对于使用 API 有明确的相关要求；

●在金融行业标准方面，已发布多部标准对 API 技术的部署、管理进行规范，如《个人金融信息保护技术规范》要求金融机构嵌入或接入 API 时，应符合相应技术规范要求，进行检查、评估和审计。以下是摘录出来在金融行业的 API 标准：

Imperva API 安全方案中最重要的一个环节 - 自动创建Swagger文件，安全团队基于现网 API 流量自动创建每个 API 应用的接口服务清单，通过该清单梳理出该业务的访问基线模型（类似于WAF的应用动态建模功能）

●将创建好的 API Swagger文件导入到https://editor.swagger.io/，可以一目了然的看到该应用所包含的每一个 API 对象的相关请求/响应的详细信息

●开发团队不会创建 API 清单文件，或者它们会不断更改 API 接口文件，因此安全团队不能及时拥有最新的 API 接口清单文件；

●部分 API 应用采用第三方的系统，应用信息非常有限，更加无法获得标准 API 接口清单文件；

●协同业务团队一起确认 API 清单的准确性，如是否包含老旧的 API 对象，传输对象的参数格式和长度，是否包含敏感数据，请求方法等是否正确，最终形成正确完整的 API 业务清单；

●END●