历史 API 演变

根据历史记录，Web API 的出现始于 1990 年底，当时 Salesforce 推出了销售自动化解决方案。当时，它是一种开放资源，可供所有人使用。

Salesforce 的自动化工具是 XML 驱动的，用于交换此工具数据的格式后来被认可为标准 SOAP API。它具有与允许或禁止请求相关的消息格式规范和编码特定规则。

大多数开发人员需要处理 SOAP 以进行 API 开发和创建。他们还需要将手动 XML 文档与 RPC 一起付诸实践。之后，开发人员需要解释 API 的端点并将SOAP 套件 POST 到该端点。这不仅解释了 API 的诞生，也是 SaaS 概念的起源。

2004 年，随着 eBay、亚马逊和 eBay 等平台的出现，世界见证了 API 进程的巨大变化，它们都投入精力开发 API。这三个平台改变了与网络和周围世界的沟通方式。更新的 API 版本与解决方案的商业方面无关。相反，它们开始为企业增加价值。

塑造现代 API 的一些关键事件包括 Flicker 和 Facebook API 的推出。Flicker 开发了一个通过云存储数字图像的平台，该平台使用支持跨不同平台共享图像并集成照片共享设施新服务的 API 开发。

到 2008 年，API 已经升级到可以独立运行并处理大量互连信息。Twilio 向我们展示了 API 就是处理整个产品所需的一切。他们推出了一款可以连接电话进行通话和发短信的 API。

什么是 API？

对于初学者来说，API 是指应用程序编程接口，旨在实现两个不同应用程序之间的轻松通信。这就是为什么它通常被称为应用程序的中间人。当我们讨论 API 时，提到 API 安全性至关重要，因为它可以保护用户拥有和使用的应用程序的完整性。

让我们详细了解 API 的含义。当今的世界由物联网 (IoT) 驱动，其中计算已集成到日常对象和操作中。物联网实施的一个现实示例是使用一个应用程序，该应用程序可以将手机与冰箱连接起来，并允许您从任何地方进行操作。使用该应用程序，可以远程操作冰箱，可以查看冰箱内有什么，甚至可以降低温度。

对于开发人员来说，API 是微服务和容器之间交换信息以及快速通信的绝佳工具。正如集成和互联互通对于应用程序开发至关重要一样，API 可以驱动和增强应用程序设计。

API 席卷互联网

在世界了解 WWW 和互联网之前，API 就已经作为专有协议发挥作用。无论分布式网络用于受限区域、目的或组织，它们都发挥着至关重要的作用。在互联网时代之前和之后，API 都发挥着相同的作用，并使计算通信成为可能。

当 Web 2.0 进入世界时，基于 Web 的工具不再只是人类的助手。它们就像孤胆英雄，可以独自处理所有操作。在此阶段，REST 声名鹊起。它用于解释 API 接口，这些接口稍后将用于构建实际应用程序。

向世界提供表述性状态转移框架 (即著名的 REST) 的人是 Roy Fielding，他在 2000 年的博士论文中建议使用这样的框架。它很快成为开发专家社区中的一种规范，并为 OpenAPI 铺平了道路。

在 Web 3.0 时代，API 在物联网和人工智能驱动设备之间的通信中发挥着至关重要的作用。API 的传统请求-响应范式必须修改为事件驱动，以便 API 的参与度得到进一步加强。

API 用例

API 在应用程序和 Web 应用程序开发领域得到广泛应用。它们是应用程序的基础元素，因为它们允许轻松交换信息。API 的一些最常见和关键用例如下：

• 单页应用程序（SPA）

使用 REST API，SPA 或单页应用程序的开发速度加快。SPA 应用程序使网站内容优化成为可能，将所有内容放在一页上，并提供出色的用户体验。

为了开发此类应用程序，使用预定义的 CSS、JavaScript 和 HTML 文件来开始 Web 服务器通信。

这里，REST 框架用于服务器端通信，而部署特定类型的框架用于客户端信息交换。

泽西岛 SPA 开发常用的 REST API 框架。Nancy Fx、Express Js 和 ASP.Net Web API。使用 REST API 进行 SPA 开发可以提高扩展性，因为它是一个无状态 API 框架，并且不受客户端为每个请求使用一个或多个服务器的困扰。这减少了扩展应用程序所投入的精力，并且消除了访问特定资源的需要。

除了 REST API 文档之外，SPA 开发中使用的客户端和服务器之间没有任何东西可以绑定在一起，使它们作为不同的实体工作。这种独立性促进了灵活的开发、测试和部署。

另一方面，如果使用动态网页框架，开发人员就不会拥有如此显著的自由。

• 公共API，企业B2B

长期以来，电话、传真和电子邮件一直是 B2B 业务的主要沟通方式。然而，技术的发展推动了基于物联网的信息交换集成的使用。Restful API在企业 B2B 通信自动化中发挥着至关重要的作用。

从客户角度来看，发布公共API可以让企业创建面向消费者的应用程序，使与外界的沟通达到最大化的效用。

公共 API 的使用可以抑制 B2B 流程所导致的迟缓，因为它们使业务流程解耦成为可能，并增强了基于机器的互操作性。公共 API 允许 B2B 客户在需要时扩展基于用户的业务，而不会增加企业的成本负担。

• 私有API，内部API服务

使用私有 API，B2B 客户可以缩短上市时间并快速推出新应用程序和工具，同时不会对现有工作流程造成瓶颈。在管理内部工作流程方面，私有 API 可以找出需要重组和现代化的领域，使企业可组合。

可组合业务模型是一种将复杂功能分解为易于处理的微型部分，从而实现创新的过程。它促进了资源的战略性使用。私有 API 支持各个级别的内部通信，并使其更加高效。

使用私有 API 时，协作和信息交换变得快捷且安全。

内部 API 使商业智能分析更加精确，因为它提供了可能导致操作障碍的系统部件的精确详细信息，并可以提高响应时间。

• 服务网格

它是基础设施层的一个组件，具有高度可配置性和低延迟性。它用于处理基于网络的结构上大规模发生的内部通信。使用这些网格可确保与容器化和临时应用程序相关的快速、安全和可靠的信息交换。

API 用于服务网格中的信息交换。由于网格的数据平面与通过系统的每个可能的数据包或请求都有联系，因此事情变得很麻烦。

使用通用数据平面和 xDS 等 API 可以使工作更轻松，并允许快速执行与检查系统健康状况、监控其性能、路由传入或传出请求、负载共享以平衡系统负担、服务发现和用户授权以防止故障相关的操作。

• 移动后端

移动后端是一种新兴的服务交付模式，通常用于移动优化解决方案的开发。这种开发模式以 MBaaS 或移动后端即服务的形式提供，让开发人员可以自由维护服务器和与服务器相关的工具。理想的 MBaaS 平台为开发人员提供了各种功能，包括用户管理、推送通知和社交登录插件。

MBaaS 源使用灵活的 SDK 来利用 API 的端点连接。通过这种方式，MBaaS 可以使用 Flutter、Unity、Iconic 和 ReactNative 等高端技术开发适用于 Android 和 iOS 操作系统的前端应用程序。

MBaaS 平台 API 的使用允许开发人员促进工作流管理、通知更新和任务规划等方面的自动化。

此外，创新的API鼓励生成应用层，用于在所使用的各种系统和服务之间进行无缝信息交换。开发人员可以为新添加的用户群设计基于需求的服务。

• 物联网 (IoT)

物联网是当今发展最快的技术之一，未来可能会支持超过 80% 的工具和软件。物联网设备/工具的开发可以通过使用 API 无缝进行，因为它们为开发提供了预定义的通信例程和协议。

由于物联网设备需要连接到客户或其他网络用户的设备才能完成信息交换，因此使用 API 可确保公开的信息安全、到达准确目的地并与其他对等设备相处融洽。开发人员可以创建基于上下文的应用程序，这些应用程序足以在不使用 UI 的情况下与外界进行交互。

REST API 是物联网设备生产中最常用的 API，它提供通过互联网协议进行的通信交换。由于物联网由互联网驱动，REST API 鼓励通过互联网进行信息交换。此外，REST API 允许开发人员实施用户身份验证和权限授予策略。

不同人的 API 看起来确实不同

在上一节中，我们向您提供了 API 的总体概述。它的用途非常广泛且多样，因此针对不同的目的，其工作方式也不同。

后端开发人员：

• 框架：一个结构良好的计划或策略，定义了操作和流程如何运作；
• 规范：基于 Swagger 的文档，描述 REST 或OpenAPI的功能。例如，一份解释电路版本 3 的技术细节的文档、一份与 Geo PC 相关的所有内容的说明、一个与默认版本不同的 GraphQL 模式或 protobuf。
• 数据和业务逻辑：以前无法想象没有 HTML 标记的操作，但现在不再如此。现在，我们可以在开发过程中拆分数据、逻辑和标记。后端开发人员更喜欢在客户端（例如移动应用程序或浏览器）之间分离数据和逻辑。这有助于他们重用和重新利用他们的代码或数据，例如单页应用程序和移动应用程序可以使用相同的数据。同样，业务集成，尤其是自定义集成，也可以通过这种方式来处理。
• 统一的移动、网络和集成后端，以改进和简化同步过程。

DevOps：

• 规范符合生产要求：例如，如果某个端点经常返回 502，难道您不应该找出原因并缓解它吗？对于其他问题和需求也必须这样做。
• 扩展：如果某个端点需要扩展来解决 504 错误，则必须找出负责的微服务、最佳流程和问题的方向（例如，REST API 信息 GraphQL）

安全：

• 新协议：我的防火墙、扫描仪和其他旧工具在升级时停止工作。该怎么办？！
• 东西方安全：我的网络内的通信没有得到很好的监控？！
• 新的安全、网络或其他 IT 合规性

为什么 API 安全很重要？

如前所述，API和API安全密不可分。关注API安全至关重要，因为API安全性较差的API容易受到攻击、黑客入侵或暴露。API主要用于交换信息、连接服务和传输数据，落入数据泄露的陷阱会给企业带来重大损失。

根据 API 交换的数据/信息的活力和重要性，企业可以采用不同的 API 安全方法。例如，用于连接到任何第三方应用程序的 API（如上述示例）需要被访问，以便能够将数据传回互联网。如果有人知道你冰箱里存放了什么，你不会担心。但是，如果同一应用程序的 API 正在跟踪你的位置，那么是时候修复它了。‍

API 身份验证方法

验证用户身份的任务至关重要，因为它可以防止 API 被滥用，并在授予用户访问存储信息的权限之前验证用户的真实性。它涉及验证试图查看或编辑 API 资源的人的身份，只允许经过身份验证的用户进行相同的操作。

1. 基于主机的身份验证

此过程包括验证主机或服务器，以便只有经过验证的用户才能访问部署在服务器上的资源。它不需要任何密钥或其他方式来启动该过程。但是，服务器应该能够事先验证登录密钥，以控制 DNS 欺骗、路由欺骗和 IP 欺骗事件。

在流程和方式上，它与 RSA 非常相似。

此处使用的参数是 yes 或 no。默认情况下，不设置参数。管理员可以通过为本地主机创建私钥或提取用于本地主机的公钥来对用户进行基于主机的验证。

2. 基本身份验证

这是最直接的 API 身份确认方案之一，该方法使用 HTTP 协议和流程设计，客户端发送带有预建标头的 HTTP 请求以验证真实性并要求提供帐户密码和用户名等凭据。此基本检查是在浏览器驱动的环境中完成的。

由于所有可能的浏览器和服务器都支持，因此基本身份验证是最常见的身份验证。凭证详细信息以明文形式在网络上共享，并使用 base64 进行编码。

它通过代理服务器运行，并授予对未托管在 IIS 服务器上的资源的访问权限。由于它无法添加加密，因此无法期望其具有很高的安全性。此外，它更容易受到重放攻击。

3. OAuth

OAuth 是开放的身份确认方法。它是一种常见的 API 真实性验证技术，涵盖用户身份验证和定义授权标准。该协议被广泛用于允许应用程序与服务器交互、存储 API。

当有人尝试登录系统时，需要请求令牌。令牌在此用作验证和批准用户身份的手段。个人/请求创建者必须将访问资源的请求转发到身份验证服务器。根据身份验证的质量和结果，服务器可以接受或拒绝该请求。

OAuth 比其他流程更安全、更可靠，因此成为许多人的首选。OAuth 的三个关键要素是 OAuth 提供商（常见的有 Google 和 Facebook）、OAuth 客户端（指拥有信息的网站/页面）和所有者（表示发出访问请求的用户）。

4.OAuth 2.0

OAuth 2.0 是一种广泛使用的 API 访问管理协议，是 OAuth 的更新版本。其功能包括通过使用 HTTP 服务为客户端应用程序启用来限制 API 客户端访问。此类协议所需的关键 HTTP 服务是 GitHub 和 Facebook。它借助代码进行身份验证，不要求用户提供凭据。

OAuth 2.0 涉及的三个因素是用户（拥有 API 想要查看或编辑权限的数据）、应用程序和 API。

使用此方法进行身份确认，可以轻松使用不同的资源解释用户数据。它可以部署用于基于 Web、基于移动和基于桌面的应用程序/设备的验证和批准。

5. SAML

SAML 代表安全断言标记语言，是使用单点登录技术进行身份确认的标准 API 流程。它表示根据提供的详细信息确认用户。一旦流程完成并验证了用户，就会授予对各种应用程序/资源的访问权限。目前，它的 SAML 20 版本正在运行。它与 ID 非常相似。只有在它的帮助下才能进行用户身份评估。

API 安全性包含哪些内容？

与您拥有的应用程序相关的 API 只能受到控制。这就是为什么 API 安全性专注于保护直接或间接向用户公开的 API。用户使用的其他方提供的 API 并不是 API 安全性的首要任务，因为可以通过详细分析传出的 API 流量来获得与此类 API 相关的宝贵见解。

这里需要注意的另一个关键点是，API 安全实践实施涉及多个团队和系统。节流、速率限制等网络安全原则以及基于身份的安全和分析等关键数据安全概念都是 API 安全的一部分。

访问控制速率限制OAuth 授权/资源服务器速率限制、配额访问规则定义和执行峰值保护同意管理和执行

内容验证监控和分析输入/输出内容验证基于人工智能的异常检测架构、模式规则API 调用序列检查基于签名的威胁检测诱饵地理围栏和地理速度检查

API 协议

根据需求，API 可以以各种形式和样式使用。所选的 API 样式（ REST 、 SOAP 、 GraphQL 、 gRPC 、 Websocet 或 Webhooks）决定了应如何应用和实施 API 安全性。在 Web API 出现之前，主要的 API 样式用途是 SOAP Web 服务。在 2000-2010 年面向服务架构 WS 时代，XML 被广泛使用。

肥皂

SOAP 是一种基于 XML 的消息传递/通信协议，即简单对象访问协议。它广泛用于计算机之间的信息交换。

该协议可以扩展HTTP，并为Web服务提供数据传输方式。使用该协议，可以轻松交换所有文档或调用远程过程。

尽管 SOAP 可用于各种消息传递系统，但它的主要重点是通过 HTTP 传输的远程过程调用。它与 CORB、DCOM 和 JAVA RMI 等其他框架有一点不同 — SOAP 中的整个消息都以 XML 形式书写。这使得 SOAP 协议独一无二且独立于语言。

休息

表述性状态转移（REST）由 Roy Fielding 提出，是基于 HTTP 协议的 Web 标准架构，围绕组合和相互关联的资源展开。REST 使用的所有资源仅使用 HTTP 标准化方法进行访问。

对于要处理的每个 HTTP 请求，REST 使用四种动词：GET、POST、PUT 和 DELETE。

API 通过 HTTP 请求运行，使用 RESTful 架构。对于开发人员来说，它是理解 API 功能和行为最简单的工具。它的使用使 API 架构更易于维护和扩展。它使内部和外部开发人员都可以访问 API。

rpc

gRPC 是一个开源、先进且高性能的框架，旨在改进老式的远程过程调用或 RPC 协议。它主要用于简化客户端和后端服务的通信和消息传递过程。它使用HTTP/2作为传输协议，这是一种二进制帧协议。

gRPC 非常轻量，比 JSON 快 8 倍以上。为了完成这项工作，gRPC 调用了一项开源技术 Protocol Buffers。借助它，gRPC 为结构化消息使用了一种非常高效且与平台无关的序列化格式。在 API 中，使用 gRPC 允许开发人员确定应该调用哪个过程并评估参数值。

Webhook

Webhook 是从一个应用程序发送到另一个应用程序的自动生成消息。换句话说，它用于在两个软件之间建立通信。它们用于发送/提取实时更新。在使用 API 会浪费时间和资源或没有持续更新的情况下，使用 webhook 而不是 API 是明智的。

由于 webhook 包含重要信息并将其传输到第三方服务器，因此在使用 webhook 期间也会实施 API 安全实践，例如执行基本的 HTTP 身份验证程序和 TLS 身份验证。

WebSocket

WebSocket 是一种双向通信协议，旨在为客户端和服务器之间提供成熟的通信渠道。在这里，通信同时发生在两端。该协议可以轻松克服 HTTP 协议的局限性。

它以 HTTP 请求和响应开始，客户端使用这些请求和响应来创建 WebSocket 连接。服务器响应该请求。建立初始通信连接后，客户端和服务器都可以使用当前的 TCP/IP 连接。数据/信息通过基本框架消息协议在此连接上流动。

XML远程过程调用

XML- RPC 是一种资源，它通过标准化通信过程使 WordPress 与其他系统相互通信。它使用 HTTP 作为传输方式，使用 XML 作为编码过程。它在 WordPress 之前就已存在，是 b2 博客工具的一部分。

工作代码存放在名为 xmlrpc.php 的文件中。此文件位于网站的根目录中。它是 WordPress 3.5 版本的默认选项，可让其移动应用程序与基于 Web 的 WordPress 安装无缝交互。

每次访问请求时，xmlrpc.php 都会共享身份验证详细信息，这会增加暴力攻击和 DDoS 攻击的可能性。出于同样的原因，用于 XML-RPC 的 API 需要采用强大的 API 安全实践。‍

JSONRPC

适合初学者。JSON-RPC 是一种超轻量级 RPC 协议，用于在基于以太坊区块链的软件/应用程序开发中发挥作用的 API。它能够解释多个数据结构和规定其处理的规则。此协议可以通过相同的套接字反复使用。JSON（RFC 4627）用作此协议中的基本数据格式。

消息队列传输协议

MQTT 是 OASIS 认可的消息协议，广泛用于物联网设备和工具开发。它非常轻量，可以通过 HTTP 进行信息交换。它的可扩展性使开发人员能够同时在数百万台设备上使用它。API 安全性达到了历史最高水平，而此协议功能齐全，因为它可以实现消息加密。可以轻松应用 TLS 和身份验证。

消息队列协议

高级消息队列协议（AMQP）是一种开放协议，用于规定消息提供者的行动方针。它应用于应用层，并广泛用于创建可互操作的系统。

该协议的实现是二进制的，可以支持各种面向消息的中间件通信，并保证消息传递的 100%。使用此协议处理的 API 必定会到达其指定目的地。

XMPP

它是一组可行的免费源代码技术，用于开发多方协作、即时通讯、多方聊天和视频通话以及轻量级中间件。PHP、MySQL、Apache 和 Perl 是 XMPP 的四个关键组件。

协同应用协议

用于物联网设备的 API 需要由标准 API 安全协议 CoAP 支持。它代表受限应用程序协议，是 RFC 7252 定义的 IETF 标准。CoA 是保护简单微控制器节点的最佳选择，可以支持通过 LPWAN 进行通信。它在 TCP/IP 堆栈层中发挥作用并请求 UDP 的帮助。UDP 在这里充当基本传输协议。

云端、本地和混合部署的 API 安全性

云服务、集成平台和 API 网关等技术领域的最新进展使 API 提供商能够以多种方式保护 API。为构建 API 而选择的技术堆栈类型直接影响用于保护 API 的程序。

例如，大型组织可能使用多个具有自己的 API 的应用程序。随着组织合并所有这些应用程序，会创建各种 API 孤岛或堆栈。与一个 API 孤岛相关的 API 安全要求可以轻松从孤岛的技术直接映射出来。

从可移植性的角度来看，使用高度可移植的安全配置至关重要，以便可以轻松地将其传输或提取到任何未来技术中。

在异构生态系统中，跨 API 孤岛的 API 安全专用基础设施被广泛用于定义 API 安全实践。API 孤岛与 API 安全基础设施之间的连接配置为 Sidecar、边带代理和嵌入在云和本地部署之间的 API。

API 安全层

API 安全是一个具有多个层次的多样化领域。每一层的重点都针对特定的 API 安全，旨在获得特定且强大的保护级别。

API 发现

API 安全的第一层专用于 API 发现，因为如果不知道目标或威胁，就无法挽救任何东西。有几个障碍使安全人员无法完全了解所使用的 API。如上所述，API 孤岛是第一个障碍，因为它会妨碍 API 可见性，因为它允许访问部分 API 列表。

 

流氓 API 或影子 API 是 API 可见性的第二大障碍。当 API 是开发的一部分并且本身充当应用程序实现时，就会发生这种情况。影子 API 是指当 API 作为应用程序的一部分开发但 API 本身被视为应用程序的实现细节并且只有一群关系密切的开发人员知道时。影子 API 不在安全人员的视线范围内，因为他们无法看到实现细节。

最后，API 会经历其生命周期。API 会不断发展，API 的新版本会出现，甚至 API 可能会被弃用，但为了向后兼容，API 会继续运行一段时间，然后就会被遗忘或逐渐消失，因为它们的流量很少。

API 发现是 API 提供商与黑客之间的竞赛，黑客一旦发现 API 就会轻易利用这些 API。为了抢在攻击者之前发现您的 API，您可以挖掘 API 流量元数据。这些数据从 API 网关、负载均衡器或直接内联网络流量中提取，然后输入到专门的引擎，该引擎报告有效的 API 列表，然后可将其与通过 API 管理层提供的 API 目录进行比较。

API 安全 OWASP

API1：2019损坏的对象级授权

API 往往会暴露处理对象标识符的端点，从而产生广泛的攻击面级别访问控制问题。每次使用来自用户的输入访问数据源时，都应考虑对象级别权限检查。

API2：2019 年用户身份验证失效

验证系统经常执行错误，使攻击者能够对令牌三思而后行，或利用执行缺陷在短时间内或永久地接受其他客户端的身份验证。破坏系统识别客户端/用户的能力，通常会破坏 API 安全性。

API3：2019过度数据暴露

考虑到非独占性执行，开发人员倾向于揭示所有产品属性，而不管其独特的敏感性，依靠用户在向客户展示之前执行数据筛选。

API4：2019 缺乏资源和速率限制

通常，API 不会对客户端/客户可以引用的资源的大小或数量施加任何限制。这不仅会影响 API 工作器的性能，导致拒绝服务 (DoS)，还会为诸如动物攻击之类的安全漏洞敞开大门。

API5:2019功能级别授权失效

复杂的访问控制策略，多级控制、多方和多任务，以及政府和公共功能之间的模糊划分，往往会导致权限缺陷。攻击者利用这些问题，可以访问其他用户的资源以及监管功能。

API6:2019批量分配

在没有根据允许列表筛选合法属性的情况下，限制用户输入的数据（例如 JSON）到数据模型，通常会导致批量分配。无论是推测对象属性、研究不同的 API 端点、阅读文档，还是在请求负载中提供额外的对象属性，都允许攻击者更改他们不应该更改的对象属性。

API7:2019安全配置错误

安全配置错误通常是不稳定的默认设计、不完整或临时的配置、开放的分布式存储、错误配置的 HTTP 标头、不必要的 HTTP 方法、宽松的跨源资源共享 (CORS) 以及包含敏感信息的详细错误消息的结果。

API8:2019注入

当不受信任的数据作为命令或查询的一部分从翻译器发送出去时，就会发生注入缺陷，如 SQL、NoSQL、命令注入等。攻击者的恶意数据可能会欺骗翻译器执行意外命令或未经适当批准访问数据。

API9:2019资产管理不当

API 往往比传统 Web 应用程序暴露更多的端点，因此相关且更新的文档非常重要。相关功能和已发布的 API 表单库也发挥着重要作用，可以缓解受审查的 API 表单和暴露的检查端点等问题。

API10:2019日志记录和监控不足

缺乏日志记录和监控，加上缺乏或不充分结合事件响应，攻击者可以进一步攻击系统、保持稳定性、转向更多系统来更改、删除或销毁数据。大多数中断报告显示，识别中断的可能性超过 200 天，通常由外部人员识别，而不是内部过程或观察。

对于 PenTest

尝试使用开源工具来破解 API ？

API 开发人员可以考虑使用 PenTest，因为这是最广泛使用的测试程序。在 API PenTest 的情况下，开发人员使用 Postman 来代理预构建的 API。使用 Postman 创建的预构建 API 测试数据将快速用于渗透测试，并在提供详细报告的同时降低测试成本。

渗透测试人员可以从报告中提取代理，并可以通过直接与 API 通信来执行多项测试。

如何才能确保组织的基础设施能够承受任何类型的数字攻击？

如果定期认真地进行 PenTest，开发人员可以找出 API 的保护级别并制定补救措施。由于 PenTest 是一项技术性任务，因此最好聘请技术熟练的团队或使用开源工具模拟 API 威胁。有关更多详细信息，请查看本指南。

API 安全最佳实践

API 安全是数据中心项目和 API 开发中不可或缺的一部分。根据 API 实施的类型和各个阶段，下面提到的API 安全最佳实践被广泛用于防范各种安全风险。

1. 加密的使用

加密的 API 不易受到攻击。用于内部和外部通信的 API 应使用 TLS 加密协议进行加密。如果可能，请尝试在两端都使用加密。应部署大多数 TLS 版本。

2. API 认证

API 身份验证是确保 API 不暴露给陌生人的最简单方法。通过 API 密钥或基本访问身份验证跟踪调用 API 的资源。这种做法会增加系统的难度并使其更加安全。

3. 充分利用 OAuth 和 OpenID Connect

OAuth 是一种旨在避免记住大量密码的机制。OAuth&OpenID Connect 允许 API 承担授权和/或身份验证的全部责任。

OAuth 不需要生成不同的网站账户，而是允许你通过不同的凭证（如 Facebook 或 Google）进行连接。对于 API，它具有相同的运作方式。API 提供商需要依靠其他第三方服务器进行 API 授权，因为 API 消费者不需要提供自己的凭证，而是交出第三方授予的令牌，

在此授权过程中，API 使用者和 API 提供者均不直接承担 API 授权责任。作为一种广泛使用的委托协议，OAuth 允许 API 提供者通过添加身份层来进一步保密 API。该附加身份层称为 Open ID Connect 标准，它使用 ID 令牌扩展了 OAuth 2.0。

4.安全专家

面对多种 API 安全实践，人们自然会感到困惑，并会选择其中一种。聘请经验丰富的安全专家来指导您使用合适的防病毒系统或 ICAP 服务器，将极大地帮助您享受强大的 API 安全性。

5.持续监控、审计和记录

预防胜于治疗。同样，跟踪 API 交互并在早期阶段发现错误也是明智之举。在服务器上审核并记录相关信息。这些日志和记录将在稍后调试时使用。要跟踪 API 的使用情况，监控仪表板至关重要。更新版本时，不要忘记将它们添加到所有 API。

6. 分享有限信息

通过 API 分享的信息越少，API 安全风险就越低。尽量在错误消息中显示尽可能少的信息。

未定制的预定义消息的内容和电子邮件主题应该被锁定，因为 IP 地址可以泄露位置详细信息。

使用 IP 白名单和 IP 黑名单是限制资源访问的好方法。API 资源访问权限应仅授予授权专业人员，并且应隐藏保存在接口上的所有关键信息。

7. 限制和配额保护

为了确保后端系统带宽符合服务器的能力，请自行限制并仅授予有限数量的消息访问权限。限制和配额有助于防止 DDOS 等危险。

8. 有效数据

服务器将要接受的所有内容都应经过两次检查和验证。任何添加的内容、大量数据以及消费者共享的信息都应经过验证。JSON 和 XML 验证是两种最广泛使用的工具，用于确定参数是否安全。它们还可以控制 SQL 注入或 XML 炸弹事件。

9. 强大的基础设施

实施更新的安全网络和最新的服务器和负载平衡软件始终可以保证 API 安全性，并使 API 足够强大以应对数据泄露。

10.关注 OWASP Top 10

此列表详细说明了最严重的 API 漏洞及其影响。专家建议参考此列表并了解您的 API 将来可能遇到的危险。此外，保护所有 OWASP 漏洞也至关重要

11. 使用 API 防火墙

就像在我们家周围建一堵墙来控制不必要的访问一样，构建 API 防火墙可以确保 API 只允许访问。在为 API 建立防火墙时，请确保添加两层。

第一层应用于执行基本的安全检查，例如关注消息大小、是否存在 SQL 注入以及立即阻止入侵者。

第二层应该是在装有高端安全机制的局域网中。

12. API 网关部署

管理良好的 API 不容易出现危险。为了轻松管理 API，我们建议使用 API 网关，因为它们允许您从头到尾控制、监控和保护 API 流量。

如何保护 API 和云原生应用

使用 Wallarm（一种可靠且完整的 API 安全工具），旨在轻松保护网站、微服务和 API 免受各种危险（包括 OWASP Top 10、机器人和应用程序滥用）的侵害。

Wallarm 的最大优点是无需手动配置规则，误报率极低。我们只提供可靠、实时的 API 安全分析和可行的解决方案。我们提供免费试用和演示，方便用户使用。该工具能够保护各种 API，例如 REST、SOAP、graphQL、gRPC。

我们经验丰富的API 安全团队足以在任何环境中保护 API。无论部署类型如何，我们都精通 AWS、GCP、Azure 和 IBM Cloud 生态系统中的 API 安全艺术和科学。