问题：面对越来越多的基于 API 的攻击，组织如何确保其 API 能够抵御损害？
Gravitee 创始人兼首席执行官 Rory Blundell： 各种规模、各个行业的企业通常依赖内部 API 来统一其业务线应用程序，并依赖外部 API 与供应商、客户或合作伙伴共享数据或服务。 由于单个 API 可能可以访问多个应用程序或服务，因此破坏 API 是一种以最少的努力破坏广泛的业务资产的简单方法。
API已成为流行的攻击媒介，API攻击的频率以惊人的速度增加 681%, 根据最近 盐实验室的研究。 保护 API 安全的第一步是遵循最佳实践，例如 OWASP 建议防范常见 API 安全风险.
然而，基本的 API 安全实践不足以保证 IT 资源的安全。 企业应采取以下额外步骤来保护其 API。
1.采用基于风险的身份验证
企业应采用基于风险的身份验证策略，以便在风险较高的情况下实施安全保护。 例如，具有发出遵循可预测模式的合法请求的长期记录的 API 客户端可能不需要对每个请求进行与以前从未连接过的新客户端相同级别的身份验证。 但是，如果长期使用的 API 客户端的访问模式发生变化（例如，客户端突然开始从不同的 IP 地址发出请求），则需要更严格的身份验证将是确保请求不是来自受损客户端的明智方法。
2.添加生物识别认证
尽管令牌作为验证客户端和请求的基本手段仍然很重要，但它们 可以被盗。 因此，将基于令牌的身份验证与生物识别身份验证相结合是增强 API 安全性的明智方法。 开发人员不应假设拥有 API 令牌的任何人都是有效用户，而应设计应用程序，以便用户还必须使用指纹、面部扫描或类似方法进行身份验证，至少在高风险环境中如此。
3. 外部强制认证
API 身份验证方案越复杂，在应用程序本身中强制执行安全要求就越困难。 因此，开发人员应努力将 API 安全规则与应用程序逻辑解耦，转而使用 API 网关等外部工具来强制执行安全要求。 这种方法使 API 安全策略更具可扩展性和灵活性，因为它们可以在 API 网关内轻松实现和更新，而不是通过应用程序源代码。 最重要的是，它允许您根据不同的风险状况对不同的用户或请求应用不同的规则。
4.平衡API安全性和可用性
重要的是不要让安全性成为可用性的敌人。 如果您使 API 身份验证措施过于侵入或繁琐，您的用户可能会放弃您的 API，这与您希望发生的情况相反。 通过确保 API 安全规则在有理由时严格但不强加不必要的要求来避免这种情况。
针对 API 的攻击没有放缓的迹象。 在设计和保护 API 时，开发人员应该超越 OWASP 建议，以提高 API 被利用的难度。
