API 安全性： 需要可编程性

无论是应用还是 API、传统、现代还是 AI应用，可编程性都是安全工具箱中处理安全问题的关键工具。

我们保证应用和 API 安全的方法之一是，在向客户和合作伙伴发布之前测试其漏洞和正确性。 测试应用和 API 的一种流行技术是模糊测试。

模糊测试涉及发送意外输入（字符串而不是数字、特殊字符、太长、太短等），以确定 API 或应用程序的响应。 强大的实现将会通过拒绝这些输入作为无效输入来处理它们。 但测试输入处理与测试执行输入处理的代码同样重要。

换句话说，应用或 API 逻辑拒绝无效输入是不够的；检查无效输入的逻辑也必须是强大的。

现在，就像应用安全领域中经常出现的情况一样，有人会设计出意想不到或没有考虑到的输入。 我们将忽略大量输入清理实现的糟糕之处，并假装它们都很强大，能够捕获 99％ 的畸形。

即使有这种乌托邦式的假设，也总有那 1% 是没人考虑到的。 这就是零日漏洞产生的方式之一。

有时它们是由于技术堆栈缺陷造成的。 可能是 Web 服务器、应用服务器、GraphQL 服务器。 也许它存在于数据源的连接器中，例如用于支持日益流行的生成式 AI 检索增强生成 (RAG) 用例的矢量数据库。或者它可能是 AI 推理漏洞的出现，例如Probllama 。 毕竟，在更广泛的应用架构中添加新的层意味着新的漏洞。

这些都是导致互联网恐慌的漏洞。 他们给我们带来了Apache Killer (2011)、 HeartBleed (2014)、 Spectre 和 Meltdown (2018) 以及Log4Shell (2021)。

这些都是无法预见的弱点。 不能指望开发人员、SecOps、DevSecOps 和 QA 能够预测它们。 他们确实不能。

无论开发人员和安全专家是否缺乏先见之明，当零日漏洞出现时，就需要采取一些措施。 尤其是如果一个组织因为运行相关技术而变得脆弱的话。 这就是风险转化为威胁的原因，而威胁需要被消除。

这就是应用服务的可编程性进入讨论的地方。

应用服务的可编程性并不是什么新鲜事。 自互联网诞生之初，各组织就一直在利用可编程性来实施各种解决方案。

数据路径中可编程性的最常见用途包括：

1. 安全： 可编程性对于减轻零日威胁和解决新出现的安全风险至关重要。
2. 应用調解： 在应用升级和迁移期间促进无缝的用户体验，支持现代化，并以经济高效的方式集成新的 API。
3. 服务编排： 将工作流程和第三方服务集成到应用中，不会对用户造成干扰，从而加快产品上市时间。
4. 可用性: 支持负载均衡和现代交付实践，如金丝雀部署和 A/B 测试。

我们知道这些很常见，因为我们的内部数据告诉我们它们确实很常见。 我们超过 70% 的客户每天都会使用可编程性来实现各种各样的解决方案。 其中一些重点关注安全问题。

因此，当我们对整个市场进行调查并发现可编程性是 API 安全性最重要的技术能力时，这并不奇怪。

支持可编程性的 API 安全解决方案的多功能性几乎是无限的。 虽然 F5 无疑是该项功能的先驱，但总体而言，它已成为应用服务的市场主流。 很少有应用服务（尤其是专注于保护应用和 API 的应用服务）不将可编程性作为其核心功能的一部分。

这是因为可编程性是减轻零日威胁的基础，并使组织能够更有意识地设计影响其系统很大一部分的补丁计划。

可编程性几乎可以做任何事情。 但在安全领域（尤其是 API 安全），它不仅仅是“有则更好”。 这是必须有的。

要了解更多 API 见解，请查看我们的application策略状况报告： API 安全。