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

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

与计算的几乎所有其他方面一样，随着开发人员不断寻找提高性能和可靠性的方法，API 技术在过去 25 年中发生了变化。 API 的设计理念和数据表示都已发展，同时数据和流量的保护方式也随之发展。 流行的 API 架构的时间线大致可以如下图所示：

• SOAP API （1998-2010）。 简单对象访问协议 (SOAP) API 使用数字签名和 XML 格式数据加密来在消息级别应用安全性。 消息级别的安全性通常比 REST API 架构风格（如下）中的安全性更全面。 然而，尽管消息级安全性因其可移植性而受到称赞，但现在仅在传统的 Web 服务中可见。
• REST API （2010 年至今）。 在过去的十年中，表述性状态转移（ REST ）成为最流行的 API 架构风格。 如今，大多数 Web API 都是 REST API。 在 REST 中，资源由唯一的 HTTP URI 标识，访问控制规则基于 HTTP 动词和 HTTP URI 之间的组合。
• GraphQL API （2020 年-未来）GraphQL 是一种新兴的 API 查询语言。 它允许前端开发人员以最适合其applications的方式自定义 API 查询，从而使前端开发人员能够掌控一切。 所有资源都通过单个 URI 进行访问。由于这种灵活性和控制力，GraphQL 变得越来越流行。

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

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

API 还扩大了风险面，并且由于跨多云架构的相互依赖性质，特别引入了不可预见的风险。 这被称为API 蔓延，可能对您的 API 生态系统的安全构成极大威胁。 与 Web 应用程序一样，API 容易受到漏洞利用、自动威胁滥用、拒绝服务、错误配置以及绕过身份验证和授权控制的攻击。

现代微服务架构的日益普及可能会加剧 API 泛滥，因为此类架构使用大量 API 来进行接口通信（南北流量）和微服务之间的通信（东西流量）。

应对 API 蔓延的策略包括：

• 实施 API 治理策略
• 创建 API 发现的单一事实来源
• 确保正确的版本控制和文档
• 提供 API 流量的指标和可见性
• 大规模应用 API 安全性

要深入了解这些策略以及如何实施它们，请阅读《对抗 API 蔓延的 5 种方法（以及您应该关心的原因）》 。

从本质上讲，API 会暴露关键的业务逻辑和敏感信息，例如用户数据、身份验证凭据和金融交易，并且越来越成为攻击者的目标；尤其是登录、创建帐户、添加到购物车和转账功能。 API 可以成为攻击者利用漏洞或弱点或暴露底层基础设施和资源的入口点。   

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

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

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

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

身份验证失败。 API 中的身份验证机制通常实施不正确，导致攻击者可以未授权访问用户帐户或敏感数据，或者执行未经授权的操作。 

对象属性级别授权已损坏。 当 API 无法在对象属性级别正确执行访问控制和授权检查时，就会出现此威胁。 如果 API 端点暴露了被视为敏感且不应被用户读取的对象的属性，它就容易受到这些攻击，这种漏洞有时被称为过度数据暴露。 如果 API 端点允许用户更改、添加或删除敏感对象属性的值（这种攻击有时称为批量分配） ，那么它也容易受到这些攻击。

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

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

JWT 发现和验证是验证 JWT 合法性以防止未授权访问或篡改的关键机制。 JWT 发现涉及查找和确认用于 JWT 验证的 JSON 编码公钥或证书，而 JWT 验证可确保 JWT 颁发者与 API 的预期颁发者相匹配。这有助于确认令牌来自受信任的来源。

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

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

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

输入清理是清理或过滤数据以删除或消除潜在有害或恶意内容的过程。 输入验证和清理有助于保护系统免受一系列攻击，尤其是注入攻击。 当攻击者将不受信任或恶意的数据插入命令或查询语言时，或者当用户提供的数据未经应用验证、过滤或清理而导致执行恶意命令时，就会发生这种情况。 注入攻击包括 NoSQL、OS 命令、LDAP 和SQL 注入攻击，以及跨站点脚本 (XSS) ，其中攻击者将恶意客户端脚本（如 JavaScript）注入到其他用户查看的网页中。

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

审计跟踪和日志通过捕获有关 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 流量和活动的详细日志，因此它们还提供实时日志记录和监控功能，这对于审计或调查事件至关重要。 

CORS 是 Web 浏览器实施的一组安全策略，用于控制和管理 Webapplications使用 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 的安全对于保护患者隐私、遵守医疗保健法规（例如美国的 HIPAA）以及维护医疗保健数据的完整性至关重要。

强大的 API 安全性是确保金融服务数据的机密性、完整性和可用性以及开放银行解决方案运行的基本要求。 API 安全不仅在实现不同金融机构、支付提供商和金融科技公司之间安全交换金融数据方面发挥着核心作用，而且还有助于确保遵守欧盟《支付服务指令 2》和美国《支付卡行业数据安全标准》等法规规定的数据加密和访问控制要求 此外，API 安全在预防欺诈和保护支持开放银行计划的第三方集成方面发挥着关键作用。  

API 安全是物联网的关键要素，确保物联网设备、applications和服务能够安全通信、保护数据并维护整个生态系统的完整性。 物联网设备通过 API 相互通信、与边缘网关通信以及与云平台通信。 API 安全性确保设备和其他生态系统组件之间交换的数据保持机密、经过验证，并防止未授权访问。 物联网网络也往往包含大量具有唯一身份的设备，API安全可以提供设备身份管理，维护设备身份的完整性，防止冒充或未授权访问。 物联网生态系统还需要具备管理设备入职、配置、更新和安全退役的能力，而 API 安全性可以帮助支持整个设备生命周期的管理，包括安全固件更新。

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

零信任模型主张“永不信任，始终验证”的原则，当应用于 API 安全时，它意味着将 API 端点和服务视为单独的实体，需要对每个请求进行身份验证和授权。 零信任假设任何实体（无论是网络内部还是外部）都不应默认被信任，并且应根据需要知道的方式授予对资源的访问权限。 它涉及实施 API 访问的最小特权原则，即仅授予特定任务或角色所需的权限，并根据不断变化的需求定期审查和更新访问权限。 零信任即使在授予初始访问权限后也会强制对设备、用户和applications进行持续验证，并根据行为和设备合规性重新评估信任级别。

区块链的核心特性是数据一旦添加到区块链中就不会改变。 这确保了通过 API 访问的数据是防篡改的，使得恶意行为者几乎不可能在不被发现的情况下更改数据。 区块链还可以将资产、访问权限或凭证标记化，用于管理和控制对 API 的访问，从而简化访问控制管理。 API 可以使用智能合约来执行访问控制策略，确保只有授权用户或applications才能与特定的 API 资源进行交互。 通过分散数据和交易，区块链减少了对单点故障（例如集中式服务器或数据库）的依赖。 这使得攻击者更难以破坏 API 安全。