保护业务意味着保护 API
API 通过其在应用层的抽象能力创造价值。 例如，使用 API 来抽象对内部系统和数据的访问可以简化和自动化对遗留 IT 系统的访问。 API 也是实现融入生态系统以及与合作伙伴整合的手段。 API 也是当今自动化和编排的主要手段，这使其成为成功的数字化转型之旅的关键技术之一。 因此，API 已成为企业创新、高效执行和货币化的战略源泉。
盈利
在数字经济中，一切能够产生收入的事物最终都将被货币化。 对于 API 来说尤其如此，研究表明 API 经济非常强劲。
- 超过十分之一 (11%) 的企业有一半以上的收入来自 API 和 API 相关的实施。 （ API 的商业价值）
- 令人震惊的是，59% 的企业通过 API 创造了 26% 至 50% 的组织收入。 （ API 的商业价值）
一体化
API 已经取代 ESB 和基于 Web 的门户，成为企业对企业集成的主要手段。 有充分证据表明，API 是数字经济中企业成功的战略组成部分。
o 超过 60% 的人同意 API 集成对他们的业务战略至关重要。 （ 2018 年 API 集成状况）
o 超过 50% 的 B2B 协作将通过 API 集成进行。 （ 2018 年 API 集成状况）
o 51% 的受访者表示，“与外部组织合作”是他们决定开发 API 的主要驱动力。
（ 2019 年 API 状况）
业务和现代应用架构（例如微服务）对 API 的依赖，使其成为那些了解获取这些端点访问权或控制权的价值的攻击者特别感兴趣的目标。 这种风险意味着应该更加关注 API 层，特别是确保对它们所代表的业务功能的访问。
身份验证不是可选的
API 的安全从访问开始。 这意味着身份验证。 开放 API 不应该是 API 访问模型的描述。 它是一个属性，意味着 API 有详尽的文档并且遵循标准。 API 的调用始终应该需要身份验证，最好还需要授权。
有几种可用的选项，在选择之前您应该了解每种选项的功能和局限性。
- 好的： HTTP 基础
HTTP Basic Auth 是默认的。 这是强制执行基于 HTTP 的流量（例如当今大多数 API）的身份验证的最简单、最常见的方法。 Basic Auth 的缺点是它需要凭证，而且众所周知，凭证通常在多个applications之间共享。 窃取（或暴露）凭证越来越多地成为攻击者获取系统访问权限的途径。 密码的强度以及存储位置/方式也是影响该方法整体安全性的因素。 总比没有好。 - 更好的： API 密钥
API 密钥比 HTTP Basic Auth 更上一层楼，因为它们是由发行者发行的（并且假设是可跟踪的）。 API 密钥被发放并用于安全之外的各种目的，包括计量和计费。 然而，它们通常是静态的，这意味着它们可能会被第三方提取和使用来冒充合法用户。 共享密钥也是一个真正的问题。 与凭证一样，密钥可以由同事和家人共享。 而且它们传播得越广，就越有可能被心怀恶意的人获取和利用。 - 最好的： 代币到期
随着 API 数量的增长，令牌的使用变得越来越普遍。 目前最受欢迎的两个令牌是 OAuth 令牌（专用于 API）和 JWT（JSON Web 令牌）。 使用 JSON 作为交换有关访问基于 HTTP 的资源的声明的标准格式及其在 API 之外的适用性，使得 JWT 成为当今最流行的身份验证和授权机制之一。 它甚至有一个RFC（7519） 。 与 XML 类似 SAML 非常相似，它会发出一个 JSON 断言来描述经过身份验证的用户的访问范围和角色。 它具有高度的可移植性，而且重要的是，它带有到期日期/时间，因此不能轻易用于冒充经过身份验证的用户。 缺点是，令牌需要做更多的工作来集成，并且并不总是得到本机支持。 这可能会导致实施过程中的错误，无意中引入被利用的可能性。
API 安全性可以直接在应用中实现，或者更好的是在 API 网关中实现。 API 网关可以通过速率限制（防止意外或故意的拒绝服务攻击）和授权等功能进一步保护 API 。 授权通过仅允许指定客户端（通常由令牌或 API 密钥标识）访问特定的 API 调用来缩小对 API 的访问范围。 API 网关还可以限制使用的 HTTP 方法并记录滥用其他方法的尝试，以便您了解尝试的攻击。
我们对applications的依赖意味着它们所依赖的 API 也需要保护。 如果您尚未开始学习基础知识，那么现在是时候开始了。 如果您想保护您的业务，您将需要安全的 API。