破除API安全迷思

2025年7月11日 · 3分钟阅读

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

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

这是我们首先解决的最持久的迷思。大多数团队认为，只要部署了API，就一定知道环境中存在什么。但现实截然不同。

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

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

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

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

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

在我们讨论的一个例子中，一个组织认为其Web UI有强大的控制措施，因此是安全的。然而，背后的底层API仍然允许未经认证的访问。这是一个常见的脱节。API不需要可见就能脆弱。

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

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

简而言之，这些工具服务于重要功能，但并非构建用于检测我们现在在API流量中常规看到的威胁类型，如破碎对象级别授权（BOLA）、僵尸端点或代理触发的抓取。最终，仅依赖WAF和网关会创造危险的安全感。

这是我们对话转向操作的地方。检测是必要的，但不够。仅仅知道攻击并不降低风险；阻止它才降低风险。没有行动的警报只是噪音。

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

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

虽然测试扮演重要角色，但它只是更广泛生命周期的一部分。你不能扫描出一条安全部署的道路。

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

那么，问题来了：API安全实际需要什么？我们已经破除了迷思，现在是时候揭示真相了。以下是Tejpal和我认为每个组织应该锚定其API安全计划的六个基本原则：

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

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