保障 API 安全：顶级安全性的最佳实践

应用程序编程接口 (API) 无处不在，它们在我们以数字为中心的生活中几乎扮演着一切的角色。每次我们在手机上启动网页或应用程序时，后台都会进行数十次 API 调用，以提供高度定制的体验。越来越多的人甚至家中的日常用品也在与 API 对话 – 从 Amazon Echo 等智能扬声器到家用电器、电表和灯泡。

但随着 API 的使用不断增长，对 API 安全性的需求也随之增长。

企业越来越依赖 API 来实现与合作伙伴、供应商和第三方应用程序的无缝集成，而 API 安全漏洞可能给组织带来严重的财务和声誉损失——一些API 安全研究显示，每次攻击的平均成本约为 610 万美元。

API 现已成为恶意行为者（即网络犯罪分子，而不是 Willem Dafoe）用来窃取数据、破坏运营、进行欺诈以及参与一系列其他对企业不利的险恶活动的主要载体。

随着 API 成为现代应用程序开发的基础，攻击面（攻击者可能通过其未经授权访问网络或系统以提取或输入数据或执行其他恶意活动的所有入口点）正在不断增加。解决方案是什么？API 安全。

什么是 API 安全？

API 安全是一套旨在保护组织 API 的最佳实践。除了基础设施安全参数外，公司还应在应用程序逻辑级别以编程方式保护 API。

应该制定适当的 API 权限和规则，以确保只有目标受众才能使用正确类型的允许 API。

API 安全是任何现代数字企业的重要组成部分。通过采取正确的安全措施，企业可以确保其 API 安全，并确保其传输的敏感数据不会受到未经授权的访问。

为什么 API 安全很重要

由于软件行业广泛依赖 API，因此提供 API 的组织有必要提高 API 的安全性和可信度。在 2023 年 API 峰会上，Ahmed Koshok 和 Tyler Reynolds（Kong 高级解决方案架构师兼 Traceable.ai 渠道和 GTM 总监）讨论了 API 安全性及其最佳实践日益增长的重要性。

“我们确实处于这个新兴 API 安全领域的早期阶段，”雷诺兹说。“但从未来 API 安全性的角度来看，它将成为现代应用程序的基础。”

API 用于访问敏感信息，包括个人身份信息 (PII)、财务数据和知识产权。目前，90% 的网络流量都通过某种 API 传输，其中大部分流量都带有敏感数据。任何未经授权的访问或数据泄露都可能给组织带来严重后果，包括法律责任、失去客户信任和声誉受损。此外，许多行业都受到有关敏感数据保护的监管要求的约束。

API 安全策略可以帮助组织遵守这些法规、避免受到处罚并维护其声誉。

雷诺兹说：“我们不能不正面解决这个问题。”

识别和管理 API 安全风险

识别和管理 API 安全风险是维护安全可靠的 API 基础设施的关键方面。

以下是组织可以采取的一些步骤来最大限度地降低 API 安全风险。

盘点和管理您的 API。无论组织拥有十几个还是数百个公开可用的 API，它都必须首先了解它们，以便正确地保护和管理它们。API 蔓延和治理是所有云和遗留基础设施中普遍存在的问题，没有人能够保护他们不知道或不了解的东西。因此，必须在注册表中记录所有 API 以定义特征（例如名称、用途、有效负载、使用、访问、上线日期、停用日期和所有者）。这将避免被遗忘、从未记录或在主要项目之外开发的影子或孤岛 API（可能是通过合并、收购或测试或弃用版本）。
监控和记录 API 活动。监控和记录 API 活动是识别潜在安全风险的重要方面。攻击者经常反复探测 API 以查找可以利用的漏洞或逻辑，因此实时监控对于攻击检测和响应至关重要。这种方法不需要预定义的策略、规则或攻击签名，因此它始终能够适应新的和不断发展的攻击。

Koshok 表示：“API 管理的两个维度是了解 API 的存在以及对 API 治理的应用。理想情况下，所有 API 都应该被了解和管理。”

一旦组织对其 API 进行盘点，Kong 就会帮助其开发 360 API 安全管理框架，以了解这些 API、使用模式、依赖关系和应用程序流以及每个端点的风险级别。

常见的安全风险

组织在实施 API 时应该注意几种常见的 API 安全风险，例如OWASP API 安全十大列表中所列的风险。

身份验证和授权机制不完善或缺失是许多公开 API 的主要问题。当 API 不强制执行身份验证（私有 API 的情况通常如此，它们仅供内部使用）或身份验证因素（客户端知道、拥有或存在的东西）很容易被破解时，就会发生身份验证失效的情况。由于 API 通常为组织的数据库提供入口点，因此组织必须严格控制对它们的访问。

API 很容易受到多种攻击，而防御者多年来一直在其网络和基于 Web 的应用中抵御此类攻击。以下攻击都不是新攻击，但它们很容易被用来攻击 API。

注入是指攻击者能够将恶意代码或命令插入程序，通常是在需要普通用户输入（如用户名或密码）的地方。SQL 注入是一种特定类型的注入攻击，使攻击者能够控制 SQL 数据库。
跨站点脚本 (XSS)是一种注入攻击，当漏洞使攻击者能够将恶意脚本（通常是 JavaScript）插入 Web 应用程序或网页的代码中时就会发生这种情况。
分布式拒绝服务 (DDoS)攻击通常通过向网络、系统或网站注入超出其处理能力的流量，使目标用户无法使用网络、系统或网站。API 端点是不断增长的 DDoS 目标之一。
中间人 (MitM)攻击是指攻击者拦截两个通信系统之间的流量并冒充对方，充当两者之间的隐形代理。使用 API，中间人攻击可能发生在客户端（应用）和 API 之间，或 API 与其服务之间。

加密不足可能导致数据泄露和其他安全事故。这包括使用弱加密算法、未能加密敏感数据以及未实施 SSL/TLS 加密来保护传输中的数据。

管理安全风险和威胁

“这些漏洞的可怕之处在于，被利用的 API 完全按照设计运行，”Reynolds 分享道。“这不是代码中的错误，而是利用 API 的可预测性，让它做一些开发人员不打算做的事情。”

这就是为什么无论您的 API 多么完善，您都需要优先考虑安全性。（我们可能听起来像是老生常谈，但这一步很容易被忽视。）API 安全性不应事后才考虑或被视为别人的问题。不安全的 API 会给组织带来很大的损失，因此请在开发 API 时构建安全性并实施强大的管理系统。

Reynolds 继续说道：“API 安全确实是一个大数据问题。要实现全面的 API 安全方法，您必须了解数据和身份，并深入了解端到端应用程序的业务逻辑。”

API 安全性最关键的方面之一是实施身份验证和授权。此步骤可确保只有授权用户才能访问 API，并且他们的访问级别适合其角色。在可行的情况下，请使用基于可靠、经过验证的身份验证和授权机制的解决方案，例如 OAuth2.0 和 OpenID Connect。

身份验证和授权

API 身份验证和授权是指验证客户端身份并控制对 API 资源的访问的过程。身份验证是验证客户端是谁，而授权是控制他们在通过身份验证后可以访问哪些内容。

适当的 API 安全性需要实施身份验证和强大的授权控制。要控制对 API 资源的访问，您必须仔细全面地识别所有相关用户和设备。这通常需要客户端应用程序在 API 调用中包含一个令牌，以便服务可以验证客户端。

使用 OAuth 2.0、OpenID Connect 和 JSON Web 令牌 (JWT) 等标准来验证 API 流量并定义访问控制规则或授予类型，以确定哪些用户、组和角色可以访问特定的 API 资源。

跨安全模型的一致性

在将安全模型应用于内部和外部 API 时保持一致有助于确保所有 API 都具有适当的身份验证和授权。这降低了在没有适当凭据或权限的情况下访问 API 的风险。使用一致的模型还可以更轻松地审核和验证所有 API 是否都正确实施了安全控制。

如果使用不同的模型，则会增加整体管理 API 安全性的复杂性。采用一致的方法，安全机制的更改只需在一个地方应用，而不必为不同的 API 分别重新实施。

总体而言，一致性可以实现更好的策略执行，降低配置错误的可能性，并且随着更多 API 的添加，更容易大规模维护 API 安全性。

建立安全通信

使用加密

所有网络流量都应加密 — 尤其是 API 请求和响应，因为它们可能包含敏感凭据和数据。所有 API 都应使用并要求使用 HTTPS。尽可能启用 HTTP 严格传输安全比将 HTTP 流量重定向到 HTTPS 更好，因为 API 客户端可能不会按预期运行。

实施访问控制

实施 API 访问控制的第一步是确定要控制访问的资源。这可能是特定端点、数据资源或 API 内的操作。
希望允许第三方通过 API 访问内部数据和系统的组织必须引入并测试控制措施来管理该访问：谁、什么、何时，以及对数据访问、创建、更新和删除的检查 —零信任安全模型。

维护数据完整性

维护 API 数据完整性对于确保通过 API 传输的数据准确、完整和一致至关重要。

验证输入

永远不要假设 API 数据已被正确清理或验证。在服务器端实施自己的数据清理和验证例程，以防止标准注入漏洞和跨站点请求伪造攻击。调试工具可以帮助检查 API 的数据流并跟踪错误和异常。

包装错误响应

包装来自 API 的错误响应可防止敏感的实现细节在面向客户端的响应中暴露。

例如，通过返回通用的“404 Not Found”响应而不是特定于框架的错误消息，底层技术堆栈保持不透明。这有助于避免无意中泄露信息，从而帮助攻击者。包装还为客户端提供了一致的错误响应格式，无论实际发生的错误是什么。客户端获得可操作的信息以妥善处理错误，而不是解析意外的服务器错误消息。

最重要的是，错误包装使 API 能够遵循故障安全默认设置，即您假设请求会失败并据此制定计划。API 可以在响应之前验证数据完整性，而不是通过未包装的错误暴露部分或损坏的内部状态。总体而言，包装 API 错误响应可提高 API 使用者的安全性、可靠性和沟通清晰度。

某些 API 会泄露过多信息，无论是通过 API 返回的无关数据量，还是泄露过多有关 API 端点的信息。当 API 将过滤数据的任务留给用户界面而不是端点时，通常会发生这种情况。确保 API 仅返回实现其功能所需的信息。此外，在 API 级别实施数据访问控制，监控数据，并在响应包含机密数据时进行混淆。

删除不应共享的信息。由于 API 本质上是开发人员的工具，因此它们通常包含密钥、密码和其他信息，这些信息在公开之前应被删除。但有时这一步会被忽略。组织应将扫描工具纳入其 DevSecOps 流程，以限制机密信息的意外泄露。