什么是API安全？主要类型和用例

理解 API安全

API（应用编程接口）是开发现代应用的基础，因为它们有助于提高应用与其他应用、服务或平台进行通信和交换数据的能力。它们使企业能够轻松地与外部平台和第三方服务集成，并通过连接各种组件来构建全面的解决方案。这促进了模块化应用开发方法的采用，使开发人员能够利用现有的服务和功能，促进代码的复用，加快开发周期，并提高工作效率。API 能够解耦和分散业务逻辑，并且这种机制还能够推动传统应用向基于 API 的架构演进，因此是现代应用的基石。

不同类型的 API

API 根据其可访问性、用途和目标受众，可分为几种类型。

• 私有 API，也称为内部 API，由组织开发和维护，供内部使用，用于在组织的基础设施中实现不同组件或服务间的通信。私有 API 并非为提供给外部开发人员使用而设计。
• 公共 API 旨在提供一种访问服务、平台或应用中特定功能或数据的方式，其对外部开发人员、第三方软件应用和公众开放。公共 API 通常用于扩展产品或服务的功能，并为第三方开发人员构建应用或集成提供支持。
• 合作伙伴 API 是公共 API 的一个子集，仅限组织的特定合作伙伴、附属机构、客户或 B2B（企业对企业）合作者使用，用于提供对某些功能或数据的受控访问。通常由身份验证和授权机制授予对这些 API 的访问权限。
• 第三方 API 由外部组织或个人开发，提供可集成到其他应用中的功能。这些 API 使开发人员能够访问外部服务、库或数据源，以增强自己的应用。它们在软件开发中被广泛使用，其通过利用现有服务或功能，来节省人们的时间和精力。第三方 API 的例子包括在旅行或旅游网页上显示自定义地图的地图 API，或显示当地天气预报的天气 API。

API Security 为什么必不可少

API 同时会扩大风险面，尤其是，由于其在多云架构中具有相互依赖性，因此会引入不可预见的风险。与 Web 应用一样，API 也容易受到各种威胁的影响，包括漏洞利用、自动化威胁的滥用、拒绝服务攻击、错误配置，以及绕过身份验证和授权控制的攻击。

API Security 不足的风险

就本质而言，API 会暴露关键业务逻辑和敏感信息（如用户数据、身份验证凭据和金融交易），并且其越来越多地成为攻击者的目标，其中，对登录、创建帐户、添加到购物车和转账功能的攻击尤其频繁。API 可以成为攻击者的切入点，使其能够尝试利用漏洞或弱点，或暴露底层基础设施和资源。

API Security 的主要类型

完善的 API 安全措施必不可少，如此可以保护数据免遭未授权访问、操纵或泄露，从而确保隐私并维持用户和利益相关者的信任，同时还可以确保 API 的机密性、完整性和可用性。

然而，由于 API 和应用正面临着许多相同的威胁，安全团队应考虑采用整合的应用和 API 安全策略。根据 OWASP 的 2023 年 API 十大安全风险，一些共同的安全风险将同时对应用和 API 造成影响，在实施安全解决方案时应对此加以考虑。例如：

• 身份验证/授权控制薄弱
• 配置错误
• 业务逻辑滥用（撞库攻击或帐户接管）
• Server-Side Request Forgery (SSRF)

这就需要制定一种整合的应用和 API 安全策略，其中的通用功能将能够同时作用于应用和 API。为应对同样的威胁或风险而运营双倍服务不仅效率低下，还会增加不必要的复杂性。整合的应用和 API 安全策略在运营、财务和架构上更具合理性。

API 安全措施的关键应用场景包括以下方面。

身份验证和授权

身份验证和授权是 API 安全措施中的基本要素。身份验证是指对尝试访问 API 的用户或系统进行身份验证，确保发出请求的实体符合其声称的身份。常见的身份验证方法包括用户名/密码、API 密钥、令牌和生物识别。授权用于确定已通过身份验证的用户或系统可在 API 中执行的操作。这包括定义访问控制规则、角色和权限。基于角色的访问控制 (RBAC) 和基于属性的访问控制 (ABAC) 是常用的授权模型。通过实施适当的授权检查，组织可以确保经过验证的客户端拥有访问特定资源或执行特定操作的必要权限。精细的访问控制可以限制对敏感 API 端点或数据（及其相关对象和功能）的访问。

开放授权 (OAuth) 协议是强身份验证和授权实践的关键组成部分。OAuth 无需用户直接与第三方应用共享用户名和密码。相反，OAuth 会授予代表受限和有限权限的访问令牌，从而降低凭证被盗用和滥用的风险。它允许 API 提供商通过范围和权限定义精细的访问控制，确保第三方应用只能访问用户授权的特定资源和操作，从而降低发生未授权访问的风险。

身份验证和授权机制实施不当会对 API 安全造成多种威胁，包括：

对象级别授权失效。当应用未能在对象或数据级别正确执行访问控制时，就会出现此安全漏洞，从而允许攻击者操纵或绕过授权检查，并获得对应用中特定对象或数据的未授权访问权限。接收对象 ID 并对对象执行任何操作的每个 API 端点都应实施对象级授权检查，从而验证登录的用户是否有权对请求的对象执行所请求的操作。

身份认证失效。通常是 API 中的身份验证机制实施不正确，从而允许攻击者获得对用户帐户或敏感数据的未授权访问权限，或执行未经授权的操作。

对象属性级别授权失效。当 API 未能在对象属性级别正确实施访问控制和授权检查时，就会发生此威胁。如果 API 端点暴露了用户不应读取的敏感对象属性，则该端点将容易受到上述攻击，这种漏洞有时被称为过度数据暴露。API 端点如果允许用户更改、添加或删除敏感对象属性的值，则也容易受到上述攻击，这种漏洞有时被称为大规模赋值。

• 功能级别授权失效。当 API 未能在功能或操作级别正确执行授权检查时，就会发生此类威胁，从而允许攻击者访问未经授权的功能。由于现代应用可以定义多种类型的功能角色和组，并涉及攻击者可以操纵的复杂用户层级，因此实施正确的授权检查可能会很复杂。
• 敏感业务访问无限制。当 API 缺乏适当的访问控制或授权检查时，就会发生此攻击，从而使攻击者能够自动访问由 API 支持的敏感业务流程。攻击者常会使用精密的自动化工具包重新调整攻击方式，如果目标的 Web 应用受到反自动化防御的充分保护，攻击者可能会转而攻击 API 背后的业务逻辑。

JSON Web 令牌 (JWT)

JSON Web 令牌 (JWT) 是一种开放标准方法，用于以简洁、独立、安全的方式在双方之间传输数据。JWT 广泛用于基于令牌的身份验证和授权。通过 JWT，用户或客户端无需在每次请求中重复发送凭证（如用户名和密码），即可向 API 服务器证明其身份和授权，从而避免在网络上暴露敏感信息。这种基于令牌的方法最大限度地缩短了暴露在潜在攻击（如会话劫持）下的时间窗口，从而增强了安全性。JWT 可以撤销，并包含过期时间，过期后即失效。这降低了令牌无限期有效的风险。

JWT 发现和验证是验证 JWT 合法性的重要机制，可预防发生未授权访问或篡改。JWT 发现涉及查找和确认用于 JWT 验证的 JSON 编码公钥或证书，而 JWT 验证则确保 JWT 签发者与 API 的预期签发者一致。这有助于确认令牌来自可信来源。

数据加密

API 使用各种加密技术来保护在客户端和服务器之间传输的数据，确保在传输过程中交换的信息机密、完整。用于保护 API 请求和响应的主要加密协议是 HTTPS，即通过安全套接字层 (SSL)/传输层安全 (TLS) 协议传输的 HTTP，它对在客户端和服务器之间传输的数据进行加密，防止恶意第三方的窃听和篡改。SSL/TLS 使用非对称加密和对称加密保护传输中数据的机密性和完整性。非对称加密用于在客户端和服务器之间建立安全会话，而对称加密用于在安全会话中交换数据。这可以防止攻击者查看或篡改在两个节点之间交换的数据（在此场景中，即为客户端与 API 服务器之间的交换数据）。

然而，为“东西向”流量（指在网络内部或在组织基础设施的不同服务或组件之间，从机器到机器的 API 调用）提供端到端加密可能具有挑战性，因为它需要生成、分发和管理多个加密密钥。确保所有通信组件都能在正确的时间获得正确的密钥非常复杂，在大规模环境中尤其如此，而且这可能会带来延迟，限制端到端加密实施的可扩展性。

输入验证和清理

输入验证和清理有助于确保从外部来源（如用户输入或 API）接收的数据安全、可靠，且不含恶意内容，从而帮助防止注入攻击和其他漏洞。验证规则定义了有效数据的判断标准。这些规则可以包括数据类型检查（例如，数字、字母、电子邮件格式）、长度限制、格式要求和自定义业务逻辑。如果输入验证失败（即数据不符合定义的标准），应用将拒绝输入，防止对数据做出进一步处理。

输入清理是指对数据进行净化或过滤的过程，旨在移除潜在的有害内容或恶意内容，或使其失效。输入验证和清理有助于保护系统避免遭受一系列攻击（尤其是注入攻击）的影响。当攻击者在命令或查询语言中插入不可信或恶意的数据时，或者当用户提供的数据未经应用验证、过滤或清理时，就会发生此类攻击，从而导致执行恶意命令。注入攻击包括 NoSQL、操作系统命令、LDAP 和 SQL 注入攻击，以及跨站脚本 (XSS)，即攻击者在其他用户浏览的网页中注入 JavaScript 等恶意客户端脚本。

速率限制和节流

这些机制可控制客户端向 API 发出请求的速率，阻止滥用或过度使用 API，以防资源被过度消耗，并保护 API 免受潜在拒绝服务 (DoS) 攻击的影响。

审计跟踪和日志记录

审计跟踪和日志记录通过捕获关于 API 请求和响应的详细信息（包括请求的发起者、已访问的端点，以及请求发生的时间），提供对 API 活动的可视性。通过分析日志，安全团队可以检测 API 活动的异常或可疑模式，如重复失败的登录尝试、非预期的数据访问，或异常的流量峰值。这些异常情况表明可能存在黑客攻击或数据泄露等安全事件。当存在安全漏洞或发生可疑活动时，审计跟踪和日志记录也可以成为宝贵的取证数据来源。

API Security 最佳实践

以下 API 安全最佳实践所侧重的策略和规程旨在抑制 API 带来的特有漏洞和安全风险。

安全的 API 设计

设计安全的 API 离不开强有力的安全控制机制，包括：实施强大的身份验证机制，对与 API 交互的用户和系统进行身份验证；使用授权控制来定义和执行访问权限，确保只有经过授权的实体才能执行特定操作；遵循最低权限原则，授予用户和系统执行任务所需的最低权限；避免权限过高，因为这会导致 API 被滥用或恶意利用；使用 SSL/TLS 等强加密技术保护通过网络传输的数据；对从客户端和其他来源接收的所有输入进行验证和清理，以防止常见的安全漏洞（如注入攻击）。

此外，保护 API 免受漏洞攻击也至关重要。这包括定期对补丁进行管理，确保所有 API 依赖项、库和框架保持最新，以应对已知的安全缺陷。为了降低 DDoS 攻击的风险，实施速率限制和节流机制至关重要，这将限制指定时间范围内可以发出的请求数量。业务逻辑滥用也是会对 API 安全造成影响的重大隐患。这些攻击利用应用的底层逻辑和流程来实现恶意目的。例如，攻击者可能会操纵 API 的业务逻辑，对特定功能或资源进行未授权访问，或外泄敏感数据。强大的访问控制和授权机制有助于确保只有授权用户才能访问特定的 API 业务逻辑功能。

总体而言，应坚持“最小意外原则”，即在设计 API 时，选择那些最不容易让用户或开发人员感到惊讶或意外的方法和惯例。API 的用户应该能够清楚地理解安全功能的工作方式以及预期行为。如果安全功能符合用户的期望和既定的行业惯例，用户犯错或误解这些安全功能的可能性就会降低。

运行时检测

运行时检测系统采用机器学习和行为分析技术，建立 API 正常行为的基准，并在检测到行为偏离此基准时发出警报。此类异常情况可能包括罕见的 API 请求模式、非预期的数据流和未授权访问企图。运行时检测的目标是实时识别并应对出现的安全威胁和漏洞，而不仅仅依赖于开发或部署阶段实施的静态安全措施。

API 网关的使用

API 网关在中心位置控制、保护和管理 API，在 API 生态系统中起到了保护层的作用。API 网关作为一个安全和管理层，可以保护底层 API 基础设施免受许多常见威胁和运营挑战的影响，包括通过执行身份验证和授权策略，以及实施流量过滤、速率限制和节流，防止 API 被滥用。由于 API 网关能捕获 API 流量和活动的详细日志，因此还能提供实时日志记录和监控功能，这对于审计或事件调查至关重要。

跨源资源共享 (CORS)

CORS 是由 Web 浏览器实施的一套安全策略，用于控制和管理 Web 应用使用客户端技术（如 JavaScript）发起的跨源请求（即不同域或源之间的请求）。CORS 通过强制实施一组 HTTP 标头，规定 Web 服务器应如何响应跨源请求。CORS 至关重要，它能够确保 Web 安全，同时允许网页从其他域上托管的 API、Web 服务或资产那里请求资源并与之交互。

在互联网上公开 API 时，为确保其安全，务必使用 CORS 策略来控制允许哪些域访问 API，确保只有受信任的域才能访问受保护的资源。应避免过于宽松的设置，以防止将 API 暴露于跨站请求伪造 (CSRF) 攻击和其他安全风险中。

定期测试、监控和更新

定期测试、监控和为软件打补丁是主动式 API 安全策略中的重要组成部分。持续监控的重点领域应包括定期的漏洞扫描和渗透测试，以帮助识别 API 中的缺陷、漏洞和错误配置，同时，静态代码分析和动态应用安全测试 (DAST) 可评估 API 代码库和运行时行为中的安全缺陷。应定期更新 API 堆栈中使用的软件组件，包括操作系统、Web 服务器、库和框架，以解决已知漏洞，因为未打补丁的软件可能会成为攻击者的主要目标。

API 保护措施的应用场景

电子商务和支付网关

电子商务公司和支付网关平台会处理大量敏感数据和金融交易，因此强大的 API 安全性对于它们至关重要，因为它们。电子商务企业在大多数客户接触点上使用 API，包括登录、产品搜索和展示、购物车、运费估算和支付处理。此外，从向老客户推荐新的商品、跟踪评论和评级，到与聊天机器人的互动，通过使用 API，企业 还能够增强客户的体验。

移动应用集成

API 是移动应用与各种服务、数据源和第三方平台之间的桥梁，因此确保 API 安全对于移动应用集成至关重要。移动应用通常需要通过 API 与后端服务器或外部服务交换数据，而 API 为应用提供了一种请求和接收数据的结构化方式。要防止安全漏洞、保护身份验证和访问控制机制，并维护应用和互联系统的整体安全态势，确保移动应用与 API 的安全交互至关重要。

医疗保健数据交换

医疗保健数据通常包括敏感和保密的患者资料，如医疗记录、诊断信息、治疗计划和账单详情等，而 API 为在医疗保健提供商、支付方和其他利益相关方之间共享敏感的患者信息提供了便利。确保这些 API 的安全对于保护患者隐私、遵守医疗保健法规（如美国的 HIPAA）和维护医疗保健数据的完整性至关重要。

金融服务和开放银行

为了保障金融服务数据的机密性、完整性和可用性，并使开放银行解决方案能够正常运营，强大的 API 安全必不可少。在不同金融机构、支付提供商和金融科技公司安全交换金融数据的过程中，API 安全起到了核心支持作用，不仅如此，它还有助于确保企业遵守法规规定的数据加密和访问控制要求（如欧盟的《支付服务指令 2》和美国的 PCI DSS）。此外，在防范欺诈和保护为开放银行计划提供支持的第三方集成方面，API 安全措施也发挥着关键作用。

物联网 (IoT) 生态系统

API 安全措施是物联网中的关键要素，它能确保物联网设备、应用和服务安全地进行通信、保护数据，并保持整个生态系统的完整性。物联网设备通过 API 相互通信，或与边缘网关和云平台通信。通过建立 API 安全，可确保设备与其他生态系统组件之间交换的数据保持机密、经过验证，并免遭未授权访问。物联网网络通常还包括大量具有唯一身份的设备，而 API 安全措施可提供设备身份管理，以维护设备身份的完整性，防止身份仿冒或未授权访问。物联网生态系统还需要能够管理设备的登记、预配、更新和安全停运，而 API 安全性措施有助于为管理整个设备生命周期提供支持，包括安全固件更新。

API Security 的未来

API 安全的目标正在不断变化，它将持续发展，以应对瞬息万变的技术环境以及日益猖獗和先进的网络威胁。以下是可能影响 API 安全性未来的一些关键趋势。

API Security 中的人工智能和机器学习

人工智能和机器学习的强大处理能力将从根本上改变 API 安全。机器学习模型可以为 API 的正常使用模式创建基准，偏离这些基准或发生其他异常情况时，可以触发警报或自动响应，这有助于防止潜在的安全漏洞。人工智能还能识别复杂的攻击模式，以及基于规则的传统系统可能会遗漏的零日漏洞。人工智能系统日益智能化，可根据不断变化的威胁进行调整和进化，从而更有效地应对新的复杂攻击，并有可能根据历史数据和新趋势预测潜在的安全威胁。这种主动方法将使安全团队能够在漏洞被利用之前解决它们。

API 零信任架构

零信任模型倡导“绝不信任，始终验证”的原则，在 API 安全中采用零信任，即表示 API 端点和服务将被视为独立实体，每次请求都需要进行身份验证和授权。零信任假定任何实体（无论是在网络内部还是外部），默认都不应得到信任，而对资源的访问权限应基于“需要知道”原则授予。它包括对 API 访问实施最低权限原则，即只授予特定任务或角色所需的权限，并根据不断变化的需求定期审查和更新访问权限。零信任会持续验证设备、用户和应用（即使在授予初始访问权限后也是如此），并根据行为和设备合规性重新评估信任级别。

区块链和去中心化 API

区块链的核心特性是，数据一旦添加到区块链中，便不可篡改。这确保了通过 API 访问的数据不会被篡改，使恶意行为者几乎无法在不被发现的情况下修改数据。区块链还可以将资产、访问权限或凭证令牌化，以管理和控制对 API 的访问，简化访问控制管理。API 可以使用智能合约来强制实施访问控制策略，确保只有经过授权的用户或应用才能与特定的 API 资源进行交互。通过对数据和交易的去中心化，区块链减少了对单点故障组件（如中心化服务器或数据库）的依赖。这增加了攻击者破坏 API 安全的难度。