如今，API不仅成为生态系统之间的交互窗口，更是构建混合业务平台的基础。未来79%的物联网流量将通过网关接入，50%的网络流量将来自物联网，而物联网将贡献超过500亿的连接。与之相对应的是危机来临，开放互联也成了黑客眼中一条通往用户端的“捷径”。事实上，已经有不少网络攻击者将API列为首选的入侵目标之一。

考虑到物联网的设备形态和功能千奇百怪，从终端、无线接入、网关，再到云平台，涉及的环节众多，要知道不少设备使用的操作系统也是不统一的，不是定制的就是非标准的，无形中为运维人员增加了负担。而在工业和制造业场景中，一些产线上的物联网设备服役时间长达数月或数年，但安全防护措施却非常有限。

数据显示，平均每家企业管理的API数量超过360种，其中有接近70%的接口会向合作伙伴开放，而开发者则可以借助API库丰富代码选择，规模往往会达到数万量级。正因如此，才会说调用API对接数据流或触发响应几乎贯穿了每个代码级的交互流程。

API的可扩展性和可用性适用于多种编程语言，这也使得使用者能够选择自己擅长的语言来进行编程。无论软件处于哪一种形式，API始终伴随其中，并且随着网络环境下的接口越来越开放，其对内部应用的影响力也会随之增加。要知道，像谷歌、亚马逊等公司的业务规模，每天进行的API交互次数至少要达到数百万量级。

然而，存在于不同IT环境中的联网设备，多数是由不同厂商“组装”起来的，硬件、软件、组件的提供方都不一样。这种情况造成的困境之一是，有时候芯片升级了可对应的软件升级并没有赶上，而安全补丁更新的时候组件又不支持。

这也就是为什么，有的物联网安全厂商会在一开始就希望将安全解决方案整合到一个平台中，而不是之后不断的打补丁。通过这种从芯片到网络、再到云的集成式管理，原有安全认证的复杂性降低了，也不用过于依赖第三方的证书授权。

当然，如果没有API，用户在虚拟环境中调用程序时就要手动完成，考虑到成千上万台虚拟机的数量，这种工作量可不是几个人能解决的。对于云计算厂商来说，能否提供足够丰富、足够开放的API，同时确保这些API经过严格的安全测试，在用户选择服务商时有着关键作用。

不过，任何事都有两面性。网络应用前端随处可见的API逐渐变成了黑客攻击的热点，一旦端口被攻破随之而来的就是大范围的用户信息外泄。通常，企业IT团队会通过API调用和管理云资源、服务编排、应用镜像等服务，而这些服务的可用性很大程度上会依赖于API的安全性，尤其是在客户引入第三方服务的时候，让API暴露在了外部环境中。

此时，API所面临的挑战往往会体现在几个方面：外部攻击、信息篡改、恶意跟踪。首先还是老生常谈的DDoS攻击，其对关键API的入侵能导致网络大面积瘫痪，并且占用大量计算资源使得程序中断。此外，如果通过API建立联系的用户端和服务器端没有经过特殊加密，很容易造成信息泄露。

其次是请求参数的篡改，采用https协议传输的明文加密后也有可能被黑客截获，进而将数据包伪造发起重放攻击。这时候，安全证书往往也是难以幸免的，因为黑客会让需求发起方使用“仿制证书”通信，从而获得看似已经被加密的内容。

再有就是黑客会有意追踪物联网设备的端口，这样可以直接获得API的控制权，或者向标的引入恶意内容设置漏洞陷阱。其实之前所说的重放攻击，就是将已经窃取到的内容再完整的发送给接收方，这也是https无法阻止的。举个例子，虽然黑客不能凭借重复信息盗取密码，但却能在获得加密口令后从后端发起攻击。

考虑到这些风险，服务商自然也要积极完善API的安全性。举个例子，客户端将密钥添加到参数传输过程中，结合口令发送给服务端，后者进行二次加密后再给出一个口令，通过比对前后两次口令的一致性来认定是否为合法请求。由于黑客无法获知签名密钥，因此既是修改请求参数也不能对其进行签名，更不能获得之后的口令。

好在，已有不少云服务商使用API认证或API网关来监控代码库中API的状态，不仅注视着流量和分析处理进程，还会执行相应的安全策略有效削减DDoS攻击的风险。有数据显示，超过60%的企业正在使用网络应用防火墙或API网关构建混合方案来保护数据。

同时，云服务商还可以提供类似的全托管服务，不仅在开发侧支持 HTTP、WebSockets、MQTT，减少了代码在设备上占用的空间并降低带宽要求，还在所有连接点范围内提供了身份验证和端到端加密服务。

可以说，API在复杂环境中扮演的角色愈发重要，自然也就成为了黑客的关注重点。除了要在应用端建立防护措施，更要在代码上线前对API进行测试，尽力消除可能存在漏洞，将风险降到更低。

关于作者

王硕，网名信平，十多年软件开发经验，业余架构师，精通Java/Python/Go等，喜欢研究技术，著有《PyQt 5 快速开发与实战》《Python 3.* 全栈开发》，多个业余开源项目托管在GitHub上，欢迎微博交流。