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

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

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

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

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

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

迷思2：“我们的API不会暴露敏感数据”

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

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

我们讨论的一个例子中，某个组织因其Web UI具有强大控制而自认安全。但幕后，底层API仍允许未经身份验证的访问。这是常见的脱节现象：API不需要可见即可存在漏洞。

迷思3：“我们的WAF和网关覆盖API安全”

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

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

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

迷思4：“检测等同于防护”

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

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

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

迷思5：“安全测试工具就足够了”

虽然测试扮演重要角色，但它只是更广生命周期的一部分。你无法通过扫描实现安全部署。

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

现代API安全实际需求

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

• 完整发现：了解所有API，而不仅仅是网关中的API
• 以数据为中心的风险建模：理解每个端点暴露的内容以及谁应访问它
• 行为检测：基于API使用方式识别滥用，而不仅仅是已知签名
• 实时阻断：如果攻击者已经进入，警报为时已晚
• 可扩展性和上下文：防御必须以DevOps速度运行并理解语义上下文，尤其在AI驱动环境中
• 业务对齐：首先保护直接关联收入或关键操作的API

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

准备深入探索？

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