API安全的学习手册_api安全完全手册

什么是API

API（Application Programming Interface，应用程序接口）是一些预先定义的接口（如函数、HTTP接口），或指软件系统不同组成部分衔接的约定。用来提供应用程序与开发人员基于某软件或硬件得以访问的一组例程，而又无需访问源码，或理解内部工作机制的细节。

通过 API，我们就算不知道如何操作，也能将的产品或服务与其他的互通。这样可以简化应用的开发，节省时间和成本。在开发新的工具和产品，或管理现有工具和产品时，强大灵活的 API 可以帮助简化设计、管理和使用，并带来更多创新机遇。

API 有时被视为合同，而合同文本则代表了各方之间的协议：如果一方以特定方式发送远程请求，该协议规定了另一方的软件将如何做出响应。

API发展简史

API 概念的出现，始于计算机时代的初期，远远早于个人电脑诞生之前。当时，API 常被当作操作系统的库，而且基本上都在本地系统上运行，仅偶尔用于大型机之间传递消息。将近 30 年后，API 走出了它们的本地环境。到了 21 世纪初，API 成为了用于实现数据远程集成的一种重要技术。

远程 API 和 Web API 的区别

远程 API 旨在通过通信网络进行互动。这里的"远程"是指 API 操控的资源不在提出请求的计算机上。由于互联网是应用最广泛的通信网络，所以大多数 API 都是基于 Web 标准来设计的。并非所有的远程 API 都是 Web API，但可以认为 Web API 都是远程 API。

Web API 通常会使用 HTTP 来传输请求消息，并提供响应消息的结构定义。这些响应消息通常都会以 XML 或 JSON 文件的形式来提供。XML 和 JSON 都是首选格式，因为它们会以易于其他应用操纵的方式来呈现数据。

REST与SOAP的区别

 随着 Web API 的不断普及，相应的协议规范也随之产生了，从而推动了信息交换的标准化：简单对象访问协议，简称 SOAP。使用 SOAP 设计的 API 会使用 XML 格式来收发消息，并通过 HTTP 或 SMTP 来接收请求。使用 SOAP 时，在不同环境中运行的应用或使用不同语言编写的应用能够更加轻松地共享信息。

相关的规范还有一个，即：表述性状态传递（REST）。遵循 REST 架构约束的 Web API 被称为 RESTful API。REST 与 SOAP 有着根本区别：SOAP 是一种协议，而 REST 是一种架构模式。这意味着 RESTful Web API 没有官方标准。正如 Roy Fielding 在论文"Architectural Styles and the Design of Network-based Software Architectures"（架构模式以及基于网络的软件架构的设计）中定义的那样，只要 API 符合 RESTful 系统的 6 个导向性约束，就算作 RESTful API：

• 客户端/服务器架构：REST 架构由客户端、服务器和资源构成，通过 HTTP 来处理请求。
• 无状态：请求所经过的服务器上不会存储任何客户端内容。与会话状态相关的信息会存储在客户端上。
• 可缓存性：通过缓存，可免去客户端与服务器之间的某些交互。
• 分层系统：客户机与服务器之间的交互可以通过额外的层来进行调解。这些层可以提供额外的功能，如负载均衡、共享缓存或安全防护。
• 按需代码（可选）：服务器可通过传输可执行代码来扩展客户端的功能。
• 统一接口：这项约束是 RESTful API 的设计核心，共涵盖 4 个层面：
  • 识别请求中的资源：请求中的资源会被识别，并与返回给客户端的表示内容分离开来。
  • 通过不同的表示内容来操纵资源：客户端会收到表示不同资源的文件。这些表示内容必须提供足够的信息，以便执行修改或删除操作。
  • 自描述消息：返回给客户端的每个消息都包含充足的信息，用于指明客户端应该如何处理所收到的信息。
  • 将超媒体作为应用状态的引擎：在访问某个资源后，REST 客户端应该能够通过超链接来发现当前可用的所有其他操作。

虽然看似有很多约束需要遵循，但是这些约束遵循起来要比遵循规定的协议容易得多。因此，RESTful API 现在变得比 SOAP 更为普及。

近年来，OpenAPI 规范已成为定义 REST API 的通用标准。OpenAPI 为开发人员提供了一种与语言无关的方式来构建 REST API 接口，从而最大程度减少不确定的因素，让用户安心工作。

面向服务的架构（SOA）和微服务架构

最常使用远程 API 的 2 种架构方案分别是：面向服务的架构（SOA）和微服务架构架构。在这 2 种方案中，SOA 的历史更为久远一些。最初，它是在单体式应用的基础上经过改进而形成的。虽然单个单体式应用也可以完成各种操作，但通过某种集成模式（如企业服务总线（ESB））在不同应用间实现松散耦合后，即可获得某些功能。

从大多数层面来看，SOA 都要比单体式架构更简单；但是，如果无法明确理解各种组件交互，SOA 也可能会进一步加剧整个环境的复杂性。这种复杂性的加剧会重新引发 SOA 想要解决的某些问题。

对于专用松散耦合服务的使用，微服务架构与 SOA 模式类似。但是，微服务架构会对传统架构进行进一步细分。在微服务架构中，服务会采用通用消息传递框架，如 RESTful API。它们会使用 RESTful API 来实现相互通信，且无需执行繁琐的数据转换处理或使用其他的集成层。使用 RESTful API 可以加速新功能和新更新的交付；甚至还可以说，是这类 API 促进了这种速度的提升。该架构中的每一个服务都呈离散状态。一个服务可以被取代、增强或丢弃，而不会影响架构中的任何其他服务。这种轻量级架构有助于优化分布式资源或云资源，而且能够支持个别服务的动态扩展。

什么是API安全

API 安全防护就是保护 API（包括拥有和使用中的 API）的完整性。

Web API 安全防护主要关注通过 API 与互联网的数据传输。

Web API安全性包括API访问控制和隐私，以及通过OWASP API Security Top 10中所述的API反向工程和对API漏洞的利用来检测和补救对API的攻击

因为他们通常可以通过公共网络（从任何地方访问）获得，所以API通常都有很好的文档记录或易于逆向工程。API对拒绝服务（DDOS）类型的事件也非常敏感，因此对于不良行为者来说，它们是有吸引力的目标。

攻击可能包括绕过客户端应用程序，以试图破坏其他用户的应用程序功能或破坏私人信息。API安全性专注于保护此应用程序层并解决恶意黑客直接与API交互时可能发生的情况。

REST API 安全防护与SOAP API 安全防护对比

大多数 API 实施属于 REST（表述性状态传递）或 SOAP（简单对象访问协议）。

REST API 使用 HTTP 并且支持传输层安全性（TLS）加密。TLS 是确保互联网连接私密性的一个标准，可以检查两个系统（服务器与服务器或服务器与客户端）之间发送的数据是否受到加密且未被篡改。这意味着，如果黑客试图从购物网站套取的信用卡信息，他们会无法读取或修改的数据。如果 URL 的开头是"HTTPS"（超文本传输安全协议），那么该网站就使用了 TLS 保护。

REST API 也使用 JavaScript 对象表示法（JSON），这是一种能够更轻松通过 Web 浏览器传输数据的文件格式。通过使用 HTTP 和 JSON，REST API 不需要存储或重新打包数据，因此速度要比 SOAP API 快得多。

SOAP API 使用称为 Web 服务安全性（WS 安全性）的内置协议。这类协议会定义一套采用保密和身份验证的规则集。SOAP API 支持两大国际标准机构（结构化信息标准促进组织（OASIS）和万维网联盟（W3C）)制定的标准，它们结合使用 XML 加密、XML 签名和 SAML 令牌来验证身份和授权。通常而言，SOAP API 因具有更加全面的安全措施而受到推崇，但它们也需要更多的管理。因此，处理敏感数据的机构更推荐采用 SOAP API。

为什么需要API安全

企业使用 API 来连接服务和传输数据。许多重大数据泄露问题，其幕后原因都在于 API 遭到破坏、泄露或攻击。受到攻击的 API 会让敏感的医疗、金融和个人数据公之于众，被不法分子利用。不过，并不是所有数据都是一样的，保护数据更不能以不变应万变。如何实施 API 防护，取决于传输的数据种类。

为什么必须将API安全放在首位

在过去的几年中，由于数字化转型以及API在移动应用程序和物联网中的核心作用的推动，API的发展已实现了天文数字的增长。这种增长使API安全成为首要问题。

Gartner在其“如何建立有效的API安全策略”报告中预测，“到2022年，API滥用将成为导致企业Web应用程序数据泄露的最常见攻击媒介。” 为了保护自己免受API攻击，Gartner建议采用“在API开发和交付周期中采用连续的方法来实现API安全，并在API中直接设计安全性”。

考虑到它们在数字转换中所扮演的关键角色，以及对它们提供的敏感数据和系统的访问，API保证了一种专门的安全性和合规性方法。

API安全需要有什么

我们一般不会把大额的钱存放在床垫之下。大多数人都会把钱存到可信的环境（银行）中，而采用分开的方式授权和验证支付。API 安全防护与之相似，所以，我们需要一个具有验证和授权策略的可信环境。

下方列出了一些最常见的加强 API 安全性的方法：

• 使用令牌。建立可信的身份，再通过使用分配给这些身份的令牌来控制对服务和资源的访问。
• 使用加密和签名。通过 TLS 等方式（见上文）加密的数据。要求使用签名，确保只有拥有权限的用户才能解密和修改的数据。
• 识别漏洞。确保操作系统、网络、驱动程序和 API 组件保持最新状态。了解如何全面实现协同工作，识别会被用于侵入的 API 的薄弱之处。使用嗅探器来检测安全问题并跟踪数据泄露。
• 使用配额和限流。对 API 的调用频率设置限额，并跟踪其使用记录。如果 API 调用数量增多，表明它可能正被滥用。也可能是编程出了错，例如在无限循环中调用 API。指定限流规则，防止 API 出现调用激增和拒绝服务攻击。
• 使用 API 网关。API 网关担当主要的 API 流量策略执行点。好的网关既能帮助验证流量的使用者身份，也能控制和分析的 API 使用情况。

API 安全性通常取决于良好的 API 管理。许多 API 管理平台支持三种防护方案，它们分别是：

• API 密钥，单一令牌字符串（即提供唯一身份验证信息的小型硬件设备）。
• 基础身份验证（APP ID / APP 密钥），双令牌字符串解决方案（即应户名和密码）。
• OpenID Connect（OIDC），基于主流 OAuth 框架的简单身份层（即通过获取基本配置集信息和使用身份验证服务器来验证用户）。

在选择 API 管理器时，要清楚它可以处理哪些防护方案，还要制定好计划，明确如何纳入上述 API 安全防护实践。

API安全的难点

API为软件和开发社区带来许多便利和好处,例如文档完备、可公开获取、标准化、无处不在、高效且易于使用等。现在，攻击者正利用API来实施自动化的“高效攻击”，从Web应用程序到云计算服务都是目标。例如，我们知道开发人员可以使用API将诸如Web注册表单之类的资源连接到许多不同的后端系统。但是，包括后端更新等任务的灵活性也为自动攻击提供了机会。

 API的安全难题或者说悖论在于，尽管大多数安全从业者会建议隐藏资源减少暴露面和攻击面，但业务上成功部署的API却倾向使资源更加开放和可用。API的安全困局实际上也是现代IT面临的一个共性问题。对于安全团队而言，这意味着制定平衡的、良好的API风险缓解策略尤为重要。

2019 OWASP清单：十大API安全风险

除了专注于通用软件应用程序的安全风险外，OWASP还为API开发人员提供了有用的指导，以降低其实施中的安全风险。鉴于OWASP组织在软件社区中的突出地位，我们在这里有必要回顾一下2019年OWASP 10大API安全风险（内容取自OWASP网站）：

• 损坏的对象级别授权

API倾向于暴露那些处理对象识别的端点，造成了广泛的攻击面访问控制问题。在每个能够访问用户输入数据的功能中，都应考虑对象级别授权检查。

• 损坏的用户身份验证

身份验证机制通常实施不正确，从而使攻击者可以破坏身份验证令牌或利用实施缺陷来临时或永久地假冒其他用户的身份。损害系统识别客户端/用户的能力会整体损害API安全性。

• 数据泄露过多

开发人员倾向于公开所有对象属性而不考虑其个体敏感性，依靠客户端执行数据过滤并显示。

• 缺乏资源和速率限制

通常，API不会对客户端/用户可以请求的资源大小或数量施加任何限制。这不仅会影响API服务器的性能，从而导致拒绝服务（DoS），而且还为诸如暴力破解之类的身份验证漏洞敞开了大门。

• 功能级别授权已损坏

具有不同层级、分组和角色的复杂访问控制策略，以及管理功能和常规功能之间的模糊不清，往往会导致授权缺陷。通过利用这些问题，攻击者可以访问其他用户的资源和/或管理功能。

• 批量分配

将客户端提供的数据（例如JSON）绑定到数据模型，而没有基于白名单的适当属性过滤，通常会导致批量分配。无论是猜测对象属性、浏览其他API端点、阅读文档或在请求有效负载中提供其他对象属性，都是攻击者可以修改权限之外的对象属性。

• 安全性配置错误

最常见的安全配置错误是不安全的默认配置、不完整或临时配置、开放的云存储、错误配置的HTTP标头，不必要的HTTP方法、跨域资源共享（CORS）以及包含敏感信息的冗长错误消息导致的。

• 注入

当不受信任的数据作为命令或查询的一部分发送到解释器时会发生注入缺陷，例如SQL、NoSQL的命令注入等。攻击者的恶意数据可能会诱使解释器执行非预期的命令，或未经授权访问数据。

• 资产管理不当

与传统的Web应用程序相比，API倾向于公开更多的端点，这使得文档的准确性和及时更新显得尤为重要。健康的主机和最新的API版本能够有效减轻诸如API版本过期以及调试端点暴露之类的安全问题。

• 日志和监控不足

日志和监控不足，再加上事件响应的缺失或无效集成，使攻击者可以进一步攻击系统，长期驻留，并横向移动到更多系统以篡改、提取或破坏数据。大量入侵调查研究表明，检测到入侵的平均时间超过200天，而且入侵检测警告通常来自外部第三方，而不是企业内部安全流程或监控来检测。

OWASP API Security Top 10 (2023更新)

API 1 对象级别授权失效（⽆变化）

对象级别授权失效这个安全⻛险在2019和2023版本中都是TOP1，是当前API⾯临最常⻅也是危害最⼤的安全⻛险，也是在渗透测试攻防对抗中常⻅的⽔平越权的安全漏洞。

API 2 认证失效（更新）

从2019API2的⽤户认证失效更新为2023API2的认证失效，更加侧重于API身份的校验和认证，安全⻛险的场景定义更丰富和更清晰，并且安全预防的⽅案也更健全，涵盖的范围更⼴和更全。不仅是之前的⽤户身份的校验，只要是API身份校验的都涵盖在内。不仅是客户端对服务端，还包含服务端到服务端等场景。当API应⽤程序的安全机制⽆法检测到身份绕过，伪造导致验证失效，都会造成严重的安全漏洞。

API2:2019 ⽤户认证失效指的是攻击者可以利⽤弱密码、会话固定、跨站请求伪造（CSRF）等⽅式来绕过应⽤程序的身份验证和访问控制机制，并以未经授权的身份访问敏感数据或执⾏操作。这个漏洞主要集中在⽤户身份验证⽅⾯。

相⽐之下，API2:2023 认证失效涵盖了更⼴泛的身份验证问题。此类型的漏洞通常涉及到逻辑错误，例如凭据重⽤、不安全的默认配置、缺乏多因素身份验证等。攻击者可能会利⽤这些漏洞来获取管理员权限、窃取⽤户数据或直接控制受影响的系统。

因此，API2:2019 ⽤户认证失效可以被看作是API2:2023 认证失效的⼀个⼦集，更加⼴泛，并且包括许多其他类型的身份验证漏洞。

API 3 对象属性级别授权失效（合并）

2019年版的OWASP API TOP 10中，API3指的是过度数据暴露，⽽API6指的是批量分配。这两个问题在2023年版本的OWASP API TOP 10中被合并为API3 对象属性级别授权失效。

API3:2019 过度数据暴露涉及API在返回响应时，未正确限制或保护敏感数据的访问，导致攻击者可以获取到⽤户的敏感数据，例如：密码、令牌、会话ID等，并利⽤这些信息进⼀步发动攻击。

API6:2019 批量分配是指攻击者将多个参数⼀次性传递给应⽤程序，以试图在不受控制的情况下修改或创建对象。这种攻击可能会导致安全漏洞，因为应⽤程序可能会接受并使⽤未经验证的输⼊，从⽽允许攻击者通过修改或创建对象来获得未经授权的访问权限。

⽽API3:2023 对象属性级别授权失效的定义为：应⽤程序在处理⽤户请求时未正确实施对象属性级别授权，导致攻击者能够访问和修改它们没有权限访问或修改的对象属性。这种安全漏洞可能会导致敏感数据泄露、身份验证绕过、越权访问等问题。相当于2019 API3和API6两个⻛险组合利⽤产⽣的危害，是这个API3:2023新漏洞的⼀部分。

API 4 未受限制的资源消耗（更新）

API4:2019 资源缺乏和速率限制更新为API4:2023 ⽆限制消耗资源，这两个API安全⻛险都涉及到API资源限制利⽤，但存在⼀定的区别。

API4:2019是关于API资源不⾜问题，这意味着API需要处理过多的请求，或者请求的速度过快，从⽽导致API⽆法提供⾜够的资源来满⾜所有的请求。攻击者可以利⽤这个漏洞发起拒绝服务（DoS）攻击，使API停⽌响应合法⽤户的请求。

⽽API4:2023则是指API的资源消耗或者负载的⼤⼩没有受到限制，攻击者可以通过发送特殊的恶意请求，耗尽API的资源。攻击者可能使⽤⼤量的并发或⻓时间运⾏的请求，以占⽤API的资源，导致其⽆法响应合法⽤户的请求。

API4:2023 是API4:2019 的进⼀步加强，更加强调资源限制策略的实施，以防⽌未受控制的资源消耗对应⽤程序或API的影响。

API 5 功能级别的授权失效（⽆变化）

功能级别的授权失效这个安全⻛险在2019和2023版本中不管是定义还是排名都没有变化，由此可⻅这个⻛险在API场景中危害之⼤，影响范围范围之⼴。这个安全⻛险⽐较贴近于在渗透测试攻防对抗中常⻅的垂直越权安全漏洞。

API 6 不受限访问敏感业务（新增）

在2019版本中是API 6是批量分配，在新版本中2019的API6合并到了2023的API3中对象属性级别授权失效。⽽2023 API 6新增为不受限访问敏感业务。

不受限访问敏感业务这是在API:2023中新增的安全⻛险，这个主要指的是敏感业务接⼝没有做合理的限制或者配置，导致可以通过⾃动化⼯具或者脚本实现不受限制的批量查询或者获取敏感数据，这个跟API4未受限制的资源消耗有点类似，但是侧重于通过⾃动化⼯具⽆限制访问敏感业务并且获取相关的敏感信息，例如购买机票或发表评论业务接⼝。

从这个变化来看OWASP想更进⼀步突出了API安全场景的独特性，区别与WEB场景的差异性。随着API传递数据量的⻜速增⻓，利⽤⾃动化⼯具进⾏API攻击是⼀种增强效率和质量的很好选择。随着⼈⼯智能（AI）、机器学习，⼤数据技术，⼈机学习等技术的发展，模拟⼈⼯操作⾃动化攻击⼿段在API攻击中变得越来越普遍。

当今API 的的攻击中⾃动化这类如影随形，⾃动化攻击使API漏洞变得更有利可图、并且这类攻击更智能且更难防范，API 通常被⽤作它们的简单⽬标。随着时间的推移，传统的保护措施（例如速率限制和验证码）变得不那么有效。例如，操作僵⼫⽹络（⽤于剥头⽪）的攻击者可以绕过速率限制，因为攻击者可以在⼏秒钟内从全球数千个位置/IP 地址轻松访问 API。

API 7服务器端请求伪造SSRF（新增）

在2019版本中API 7是安全配置错误，在2023新版本中API 7由新增的服务器端请求伪造SSRF代替，⽽安全配置错误在新版本中并没有被取消，⽽是排名降到了API 8 ，依然占有⼀席之地。

服务器端请求伪造SSRF这是在API:2023中新增的安全⻛险，在 2021 年的OWASP Web TOP 10 应⽤程序漏洞中已经榜上有名，这次也包含在最新的 OWASP API TOP 10 2023 列表中，可⻅该漏洞的严重性，表明更多的API 可能⽐注⼊更容易受到SSRF 的攻击。

API 8 错误的安全配置（排名下降）

在2019版本中API 8是输⼊型注⼊相关的安全⻛险，但是随着API发展以及安全意识、措施、安全开发，和安全防护加强，此类型的安全⻛险在API场景中越来越少，⻛险也相对减少，所以在2023新版本中直接被剔除了，不包含在TOP10中。变成了在2019 API 7 错误的安全配置，排名下降⼀名，在新版本是API 8 错误的安全配置。

API 9 存量资产管理不当（更新）

API:2019的资产管理不当更新为API:2023的存量资产管理不当。这两个⻛险都是跟资产管理的相关，但是API2023更侧重为资产的管理不当，即为对过时的历史API资产、淘汰的API资产测试API，未打补丁的API资产，未做部署记录的API资产，以及跟第三⽅系统进⾏数据共享的API资产，对上述这些资产缺乏系统记录、管理导致不同的安全漏洞。

API 10 API的不安全使⽤（新增）

删除了2019版本中的API 10 ⽇志与监控不⾜，新增了API 10 API的不安全使⽤。这个主要侧重于API在使⽤中的⼀些安全⻛险，例如供应链第三⽅API使⽤，信任且不验证与外部或第三⽅ API 交互。例如在未加密的通道与其他API 交互；在处理数据或将其传递给下游组件之前，没有正确验证和清理从其他 API 收集的数据；不限制可⽤于处理第三⽅服务响应的资源数量；不为与第三⽅服务的交互实现超时等。

API滥用实例

API的自身设计决定了它是无状态的，假定初始请求和响应都是独立的，且并包含完成任务所需的所有信息。无论是直接访问，或作为移动或Web应用程序的一部分对API进行调用，都可以改善用户体验和整体性能。但攻击者也很容易编写脚本并自动执行攻击，如以下两个示例：

账户接管和浪漫欺诈：Zoosk是一个著名的约会应用程序。攻击者反编译了Zoosk应用程序以发现账户登录API。然后，他们使用自动化攻击工具包执行账户接管攻击。在某些情况下，被盗用的账户被用来与其他Zoosk用户建立发展个人关系网络，当家庭成员突然死亡或生病时，攻击者会借机向联系人索要钱财实施诈骗，毫无戒心的用户通常会将钱捐给攻击者。在实施Cequence之前，Zoosk的感情诈骗平均每次作案获取的收益高达1.2万美元。现在，随着API安全的加强，此类攻击几乎消失，Zoosk不但大大增强了用户的信心还提高了品牌知名度。

账户接管和财务欺诈：API成为自动攻击目标的另一个案例是某大型金融服务客户。该客户发现攻击者锁定其移动应用程序登录API环节来执行账户接管。如果成功，攻击者可通过开放资金转账（OFX）API进行转账，实施财务欺诈。而OFX是用于在金融服务社区内进行资金转移的行业标准API，因此，这些API是公开可用的，并且文档齐全，以方便使用。

API的无处不在和无状态本质在许多方面都是有益的，但是它们也带来了传统安全技术无法解决的众多挑战。API没有客户端组件，因此传统的防御技术（如Captchas或JavaScript）和移动SDK工具无法有效地防止自动攻击。通常，重定向和cookie分配并没有指定的浏览器或者移动应用，结果是API和关联的应用程序未受到充分保护。

API安全的未来

目前来看，API安全网关是各个企业保护API安全的有效手段。API安全网关是一种便捷的保护API安全的工具，API安全网关可以利用流量过滤以及监控等方式对入侵进行检测并防止黑客攻击。即使目前市场上已经出现了一些API安全防护产品和解决方案，但是由于在API海量数据中检测威胁并进行防护还是面临着很多挑战，在复杂多样的环境下进行防护是很难做到防护的智能化。此外攻击者的攻击手段日新月异，变化很快，如果设计弹性的管理系统对API服务进行安全监控是未来需要解决的问题。

在未来智能API安全解决方案会成为解决API安全问题的一个有效方法，而且已经在业界多次提及。使用人工智能和机器学习技术在海量API流量中进行威胁发现和安全防护，并利用AI模型的学习能力，在不同环境下动态的对API正常行为模式进行学习与积累，将有关行为的前置知识学习出来，然后自适应的在环境下对API异常活动进行识别并阻断，实现API安全的智能安全防护策略。

API的安全展望

1. 聚焦安全的API设计

一提到安全，人们往往想到的是复杂性、甚至是不便。因此，API设计的易用性和可扩展性，才是吸引API开发人员、乃至用户的关键战略秘诀。在实践中，当开始着手为某个微服务构建公开的API时，就应该认真考虑如何设计API的安全性。

只有在设计之初融入了安全性，特别是用户隐私方面的管控，才能节省后续补救与整改的时间和资源。业界著名的RestCase API平台正是通过各种AI和复杂的算法，以方便用户在设计阶段去检查和验证自己的API。同时，它能够给出如何处置API安全性方面的各种建议。

2. 人工智能(AI)驱动的API安全性

目前，在不同的行业，开发人员通过将系统的API与海量的数据相集成，在计算机视觉、空间位置、嵌入式应用、Web网格、移动文本数据、以及自然语言处理等领域，得到了很好的商业智能化应用，和对发展趋势的预判。

通过对于不同实时数据源的持续检测与分析，各类应用具备了更快、更智能的响应能力。

与此同时，我们应该利用好丰富的数据资源，运用AI相关的趋势分析能力，对于调用API的流量进行深度分析，进而侦测到各种历史攻击与异常，并通过自动化的修补措施，以防止后续攻击的再次发生。

例如，某些针对特定API的DoS攻击源，会在网络中扫描并攻击那些设计方案欠佳，且未对访问请求实施流速限制的API。有时候，某些API节点会在算力(computation)上非常消耗资源。

例如：那些需要通过哈希算法来进行身份验证的逻辑。因此，一些经验丰富的攻击者，经常会有目的性地利用并向此类节点发送垃圾邮件，以拖垮或破坏整个系统。

3. 机器学习(ML)驱动的API安全性

如果说AI主要是用于对攻击进行智能判断的话，那么ML则主要能够用于提取威胁的特征。通过开发带有ML功能的智能API，运维人员能够有效地管理各种具有挑战性和新出现的威胁模型。

运用此类API的安全性，我们将能够更加准确地识别和标记出各种异常行为，判断出恶意攻击的发展趋势，以及识别和阻止在多种环境、及情况下针对API的攻击行为模式。

可以说，有了持续学习功能对于API的加持，我们便可以在无法预知攻击源、以及预设应对策略的情况下，及时识别出正在发生的异常行为。

目前，广泛用于各种API安全方面的机器学习算法，包括：朴素贝叶斯、KNN最近邻(K-Nearest Neighbors)、决策树、随机森林、支持向量机、深度学习、以及神经网络等。

4. 小结

随着现代化技术的日新月异，API安全性已日渐成为了网络应用方面的主要技术需求之一。目前，AI和ML作为有效且智能的工具，已经逐渐被应用到了协议栈的各个层面上，以实现API的全栈安全防护。当然，就下一步发展趋势来看，开发人员需要进一步加大对于API业务模型、分析能力、技术蓝图、以及合规性与标准化方面的深入研究与开发。