我们现在的理解世界已经逐渐由云计算 、移动设备和微服务构成  。全及几乎我们每一个交互的何开应用都由API支持 ，尤其是理解在那些领先的云服务供应商、移动应用和微服务环境中。全及这就让API成为了组织攻击面的何开一个关键部分。

Akamai估计
，理解大约83%的全及互联网流量都是基于API的 。其他的免费模板何开研究 ，比如像Salt Security认为，理解API攻击从2021年到2022年增长了600%；而Gartner则预计
，全及90%的何开web赋能应用会因为暴露的API形成更大的攻击面。最近由Imperva的理解研究则表明
，有隐患的全及API导致组织的损失，每年大约会在400亿美元到700亿美元之间 。何开

另一个导致API攻击面扩大的关键因素是K8s和微服务的模板下载使用。最近一项研究发现了超过38万个暴露的K8s的API服务器 
，这足以引起担忧——毕竟K8s的API服务器是容器部署的核心控制组件。这同样表明 
，API的安全性被很少关注，尽管API已经是提升现代数字生态的粘接剂。

API不仅用于接入和请求数据 ，还会在流程中进行数据富集和修改等行为 。云计算这就意味着API自身不仅需要安全，他们当中流动的数据本身也需要安全 。

这一现实强调了在关注API安全时 ，离不开应用和数据安全的最佳实践。和许多其他领域的技术一样 ，大部分企业在建立他们自己的API库这个基础的任务时，就挣扎不已 。这就表明他们缺乏对他们有哪些API、和哪些API交互、以及API和哪些攻击面关联的可视化能力 。服务器租用

像Resurface Labs和Traceable AI这样的组织已经开始应对这个问题 ，但是要做的工作依然很多 。以下三点是组织应该开始理解他们的API攻击面情况以及其潜在的隐患 。

如何开始评估API攻击面

API安全对那些刚开始做安全的组织来说是一件令人头疼的任务，尤其对于那些API库杂乱无章的大企业而言 。也就是亿华云说，需要一系列有效的措施和方法论 ，才能处理这个庞大而又无法解决的安全领域。这一方式需要结合治理 、基础设施安全和应用级别的最佳实践 ，才能降低组织的风险 。

除了将组织现有的API全部都归库以外，一个可能更好的起步方式，是识别和理解最常见的建站模板API安全问题。幸运的是
，OWASP社区已经有了API安全TOP10的清单 。这个清单包括了受损对象 、用户授权/认证 、过度数据暴露 、缺乏速率限制等风险。

受损的对象级别授权是指破坏了确保用户只能接入他们被授权的对象的代码级结构。这一风险又回到了最小权限接入控制的老问题
，这一点在零信任中被持续推动。

受损的用户认证则有多种形态的表现，包括脆弱的认证机制
、在URL中存在敏感的认证信息
、凭证填充等等 。这些都是恶意人员通过已经获取的认证信息反复尝试，以突破认证交互。这些脆弱性的解决方式包括了理解认证的流程、机制，并且使用行业标准的认证方式。

过度的数据暴露简直是一个太过于常见的问题了
。当和API相关的时候，这个隐患往往发生在API给用户回复数据时，将不应该暴露的敏感数据进行了回传。组织解决这类问题的方式包括验证API响应中包含的数据，确保敏感数据不会不经意中被包括其中。组织也应该部署响应验证机制 ，保证敏感数据不被暴露 。

和其他常见的隐患相比，缺乏速率限制控制更多会影响系统的可用性 ，而非机密性或者完整性。鉴于API经常作为现代微服务
、云和移动应用之间的粘连剂 ，最终都要为客户实现价值并且创收，可用性的影响非常关键。业务中断意味着收入或者用户信任的损失。如果在公共事务领域或者国家领域 ，就会对市政服务或者国家安全打来极大冲击。

这些问题可能对那些经验老到的安全实践人员而言非常明显 ，毕竟认证、授权和DoS攻击司空见惯。换种说法 ，将以上组织内部和互联网上的API问题都考虑进去 ，加上来自恶意份子针对API攻击的高速增长速率 ，潜在的风险就越发复杂 。

API导致的横向移动

由于API经常作为应用和数字环境的前门工作，针对API的攻击经常会进行系统之间的横向移动。API能够作为一个攻击的起点，然后被用于接入下层系统 
、工作负载和数据。这就让保护API极其重要 。API的主要攻击手段包括对象和用户级别的认证和授权。因此 ，恶意份子并非只是针对API
，而是API可以接入并传输的数据 ，以及它们身后的下层系统。

对API安全更多的关注

尽管说许多攻击方式并不是只针对API的，但是一旦将这些攻击和API在现代数字生态中的大规模使用结合到一起，就会有很大问题
。幸运的是 ，一些趋势正在逐渐显现，包括对API安全企业和产品的加大投资 、更多的API安全指导，以及日益增长的业内对API安全引发问题的意识。

如果API已经成为连接现代数字生态的系带，那我们就要必须要确保这些系带非常坚固，因为我们不需要一个用泡泡糖和鞋带连接的生态。尽管说传统基于边界的安全可能已经逐渐失效，API依然是现代系统的一个关键入口以及枢轴点
。这不仅包括了对外的系统 ，同时也有内部交互的系统 。

我们同样能看到越来越多在软件供应链方面的努力。这条链通过API为主要方式，将软件驱动的系统联系在一起。这表示API安全作为更为广义的软件供应链生态的关键组件
，确保整个链条的安全性。

点评

API安全一定程度上已经不能说是一个新话题了，毕竟在过去一年中我们看到了大量的相关内容 。但是，API安全的落地始终不怎么理想。

一个很重要的原因就是在于API本身遍布了数字环境中各个方面，无论是从应用角度 ，还是从数据角度
，都无法完整描述API安全包含的内容。多样的应用场景必然会带来API可视化管理的困难；快速的业务发展与IT技术演化也必然导致当前环境中的API数量已经相当庞大 ，且难以管理
。

从API面临的风险入手确实一定程度上能够缓解初入API安全时的手足无措，但是依然无法完全解决API可视化管理的问题
。从当前来看，很难有一个企业能够单独
 、完整地囊括整个企业的API安全解决方案 ，正如本文最后提到的那样 ，API安全也涉及到了软件供应链方面的问题，而这同样是一个需要多方协同才能解决的领域。