破除API安全迷思

日期：2025年7月11日
阅读时间：3分钟

最近我与应用安全和DevSecOps领导者Tejpal Garwhal进行了一次对话，旨在破除一些最常见的API安全迷思。从僵尸端点到WAF和网关的局限性，我们探讨了实际情况以及安全团队需要做出的改变。以下是关键要点的快速概述，但完整内容请观看网络研讨会。

迷思1：“我们知道拥有哪些API”

这是我们解决的第一个也是最持久的迷思。大多数团队假设只要部署了API，就一定知道环境中存在什么。但现实却大不相同。

Tejpal指出，API蔓延经常在无人察觉的情况下发生。开发人员在短时间内构建和部署端点，文档滞后，不同团队可能假设其他人在跟踪记录。实际上，没有任何一个团队能完全掌握API清单。

更糟糕的是，许多团队依赖API网关或管理平台作为真相来源，但这些工具只跟踪经过它们路由的内容。它们无法捕获临时部署的端点或遗留代码库中遗忘的旧API。

我们一致认为：没有完整的可见性，保护API就是猜测工作。

Tejpal和我经常听到加密解决了数据暴露问题的说法。只要使用HTTPS，就假设一切安全。然而我们讨论到，传输或静态加密并不能解决谁可以访问数据以及如何通过业务逻辑暴露数据的问题。

Tejpal强调开发人员通常默认过度共享。没有严格的设计边界，API倾向于返回完整数据对象而不是最小字段。再加上糟糕的访问控制或包含敏感细节的日志记录，就形成了隐性责任。

在我们讨论的一个例子中，某个组织认为其网络UI具有强大控制措施就很安全。然而在幕后，底层API仍然允许未经身份验证的访问。这是一个常见的脱节现象。API不需要可见就能存在漏洞。

我们都见过这个迷思导致问题。它基于对传统工具实际功能的误解。

例如，WAF可以检测基本注入攻击，但通常难以处理GraphQL和gRPC等API协议，或者深度嵌套或批处理的请求。同样，API网关可以管理身份验证和路由，但并非设计用于解析和检查请求逻辑或标记业务滥用。

简而言之，这些工具具有重要功能，但并非为检测我们现在在API流量中常规看到的威胁而构建，如Broken Object Level Authorization（BOLA）、僵尸端点或代理触发的爬取。最终，仅依赖WAF和网关会创造危险的安全错觉。

我们的对话在这里转向了运营。检测至关重要，但还不够。仅仅知道攻击的存在并不能降低风险；阻止攻击才能。没有行动的警报只是噪音。

Tejpal强调许多组织拥有能生成令人印象深刻的报告的工具，但缺乏在攻击发生时进行干预的工作流程或覆盖范围。等到检测被分类处理时，损害可能已经造成。

我们讨论了实时阻止而不仅仅是警报的必要性。特别是考虑到自动化机器人和AI代理正在大规模探测API，现代防御者不能只做出反应；他们必须预防。

虽然测试起着重要作用，但它只是更广泛生命周期的一部分。你不能通过扫描来实现安全部署。

我们都同意安全需要左移。组织需要在设计中纳入威胁建模，并在API上线前验证安全合同。但我们也强调了一个经常被忽视的概念：右 shielding。即使构建了安全的API，攻击者也不会停止尝试。你需要能够适应当前情况的运行时保护。

这就引出了一个问题：API安全实际需要什么？我们已经破除了迷思，现在是揭示真相的时候了。以下是Tejpal和我认为每个组织应该基于的六项基础原则：

让我们印象深刻的一点是，许多API安全策略仍然作为技术练习运行，与业务隔离。但如果API支持支付、库存或客户数据，它就是业务本身。安全决策必须反映这一事实。

然而，这篇博客只是我们对话的表面内容。如果任何内容引起共鸣，我鼓励您观看完整对话。我们涵盖了真实世界的数据泄露、演示被忽视风险的例子，并介绍了使开发、安全和运营围绕共享威胁模型对齐的现代策略。[在此观看网络研讨会]。