什么是API安全？

在开放API、移动APP、SPA等应用场景，REST API已经成为默认选择，REST API Endpoint在公网上处于‘透明状态’。因此在设计、测试及部署REST API 时，安全性问题是一个必须要考虑的重要方面，避免因隐私数据风险、数据泄露、资金风险等触发相关安全法律及法规。本文从API安全威胁、API安全框架、身份验证模型等多个方面进行概要介绍。

API安全是什么

开放式网络应用程序安全项目（OWASP）将 API 安全定义为：重点关注了解和减轻 API 独特漏洞和安全风险的策略和解决方案。

IBM将API安全定义为：是指保护应用程序编程接口(API) 免遭滥用、恶意机器人攻击和其他网络安全威胁的实践和程序。它作为 Web 安全的一个子集，但特别关注 API，这对于企业 IT 管理越来越重要。

RESTful API 和 SOAP API 是两个受欢迎的选择由于其广泛采用和独特的功能，REST 非常适合实现 Web 服务。REST 的简单性和灵活性对现代 Web 应用程序很有吸引力，而 SOAP 的强大标准和内置安全性适合企业级系统，它们的安全性最为大家关注：

API 攻击数量

2021 年 2 月， Salt Security 对近 200 名安全、应用和 DevOps 专业人士进行了调查，了解他们对 API 的担忧。结果显示，91% 参与调查的组织在过去一年内遭遇过与 API 相关的问题。

54% 报告发现其 API 中存在漏洞，46% 指出了身份验证问题，20% 描述了由机器人和数据抓取工具引起的问题。

例如， Peloton 在 2021 年泄露了其 300 万用户的数据，原因是一个漏洞允许访问 Peloton 服务器上用户的私人帐户数据，甚至是私人资料。该漏洞允许任何互联网用户访问订阅者的个人信息，如年龄、性别、位置、生日等。

这些信息很容易检索，不需要特殊的黑客工具——只需要知道如何使用浏览器查询和修改数据元素。

为何会出现API安全风险？

出现API安全漏洞的原因可能如下：

API 不是漏洞管理程序的一部分，因此被忽视
信息安全团队缺乏彻底测试 API 的知识
API 经过通用测试，误判会给组织带来虚假的安全感
API 仅由开发团队测试
不会以对抗心态考虑 API

为什么 API 安全很重要？

API 在现代数字架构中占据着核心地位，因为它们能够无缝集成各种系统，增强互操作性和数据交换。这种重要性意味着 API 安全性不应是次要考虑因素，而应是数据安全的基本要求。

现代应用程序严重依赖 API 来运行并与第三方应用程序和软件进行通信。API 允许外部客户端高效无缝地请求数据和服务，但存在固有的安全风险。非常 API 的功能使其对企业有价值 — 应用程序和系统之间的无缝数据交换 — 也使它们成为黑客的有吸引力的目标，因为它们在数据架构中引入了更多的漏洞。

与 API 相关的违规行为正在增多， 60％的组织过去两年内，有 74% 的组织经历了三次或三次以上的入侵，23% 的组织经历了六次以上。这些数字表明安全漏洞一直存在。API 数据泄露的后果非常严重，受影响的组织面临知识产权盗窃、财务损失和品牌受损。

有哪些API安全漏洞？

如果没有得到适当的保护，API 端点可能会允许恶意行为者未经授权访问敏感数据、中断服务操作或两者兼而有之，从而造成潜在的灾难性后果。常见的API安全漏洞包括：

1. 注入攻击

在注入攻击中，危险代码被嵌入到一个不安全的软件程序中，以发起攻击，其中最著名的是 SQL 注入和跨站点脚本攻击。实际上，这种暴露可以通过将不受信任的数据作为查询或命令的一部分传输到 API 中来操作。该输入随后由解释器实现，这可能会导致攻击者获取未经授权的信息访问权限或造成其他损害。

2. DoS 攻击

在拒绝服务（DoS）攻击中，攻击者在大多数情况下会推送大量消息，请求服务器或网络建立由无效返回地址组成的请求。如果没有采取适当的安全防范措施，这种攻击能够使 RESTful API 处于无法运行的状态。最近，无论 API 是否公开，其他人（包括攻击者）都可以访问它。

3. 身份攻击

身份攻击者利用身份漏洞，可能绕过或控制 Web 程序，从而破坏 JSON Web 令牌、API 密钥、密码等。

4. 敏感数据泄露

由于在传输中或静态时缺乏加密而导致的敏感数据暴露可能会导致攻击。当应用程序无法正确保护敏感数据时，就会发生敏感数据泄漏。这些信息可能是私人健康信息、信用卡信息、会话令牌、密码等，而且包含越多的信息越容易受到攻击。敏感数据需要很高的安全性，除了在与浏览器进行交换时采取非常规的安全做法外，还包括静态或传输中的加密。

5. 访问控制攻击

访问控制，在某些情况下称为授权，是一个 Web 软件允许某些人而不是所有人访问它的功能和内容的方式。缺少访问控制或访问控制不足可能会使攻击者可以控制其他用户帐户、变更访问权限、变更数据等，从而导致访问控制攻击。

6. 参数篡改

这是一种基于操作客户端和服务器之间交换的参数来修改应用程序数据（例如，用户凭据和权限、产品价格和数量等）的攻击。通常，这些信息存储在 cookie、隐藏表单字段或 URL 查询字符串中，用于增强应用程序的功能和控制。

7. 中间人攻击(MITM)

它是指攻击者秘密地更改、拦截或中继两个交互系统之间的通信，并拦截它们之间传递的私有和机密数据。MITM 攻击分为两个阶段：拦截和解密。

API安全设计原则

论文“信息的保护计算机系统”，由杰罗姆Saltzer和迈克尔·施罗德，提出8个的设计原则，同样适用于RESTful-API。

最小权限：实体应该只具有所需的权限集来执行授权的操作，而不再执行。可以根据需要添加权限，并在不再使用时撤消。
失败保护默认值：用户对系统中任何资源的默认访问级别应被“拒绝”，除非他们已明确授予“许可”。
机制经济：设计应尽可能简单。所有组件接口和它们之间的交互应该足够简单易懂。
完全中介：系统应验证其所有资源的访问权限，以确保它们被允许且不应依赖缓存的权限矩阵。如果正在撤消对给定资源的访问级别，但未在权限矩阵中反映，则会违反安全性。
开放式设计：该原则强调了以开放的方式构建系统的重要性 – 没有秘密的机密算法。
权限分离：授予实体权限不应完全基于单一条件，基于资源类型的条件组合更好。
最不常见的机制：它涉及在不同组件之间共享状态的风险。如果可以破坏共享状态，则可以破坏依赖于它的所有其他组件。
心理可接受性：它指出安全机制不应使资源更难以访问，而不是安全机制不存在。简而言之，安全性不应该使用户体验变得更糟。

API描述规范自带的安全要求

REST API 安全

REST（表述性状态转移）API 通常使用 HTTP，并依赖 HTTPS 等机制进行加密、OAuth 进行授权以及 JWT（JSON Web 令牌）进行安全令牌交换。它们的无状态性质意味着应用程序必须单独验证每个请求，从而增强安全性。REST 在选择安全协议方面的灵活性允许更容易但需要仔细配置以防止漏洞。

SOAP API 安全性

另一方面，SOAP（简单对象访问协议）API 在其协议中内置了 WS-Security 安全性。SOAP 包括消息完整性、机密性和身份验证的标准。 SOAP 可以使用安全套接字层 (SSL) 或传输层安全性 (TLS) 用于加密. 尽管如此，其消息级安全性确保即使传输层受到威胁，消息仍保持安全。SOAP 的严格标准使其本质上更安全，但实施和维护也更复杂。

API安全最佳实践

REST是一个架构约定，在该约定中，缺少安全特性相关的内容。经过这些年的发展，市场总结了一些REST 的 API安全最佳实践，有些已经默认实现在网关产品、有些需要开发者自己负责，供大家参考：

1、始终强制使用TLS加密，网关产品可提供
与其他类型的敏感 HTTP 流量一样，将 TLS 用于 RESTful API 有助于确保对 API 用户和 API 端点之间的所有通信进行加密。这对于 REST API 安全性和 Web 应用程序安全性同样重要，因为生成的 HTTP 流量包含敏感的身份验证详细信息，如密码、API 密钥或令牌。

2、API秘钥，部分网关产品可提供
API密钥可用于请求方身份标识，用API秘钥加密请求内容及响应内容。常用方式有’对称秘钥、非对称秘钥‘等，避免使用Appcode模式。B2B模式的API网关必用API秘钥；自有APP到API网关时，常用非对称秘钥模式+其它手段来标识‘APP’，避免套壳等风险。

3、身份认证，三方产品可提供
认证是指验证用户身份的过程，常见的认证方式包括 HTTP Basic 认证、SAML、Token 认证、OAuth 2.0 等。

4、授权模型，三方产品可提供
授权是指验证用户是否有访问特定资源的权限。通过API访问内部数据和系统的组织必须引入和测试控制来管理这种访问:何人、内容和时间，以及对数据访问、创建、更新和删除的检查——零信任安全模型。

5、不在URL中包含敏感信息，做URL过滤，开发者负责
一个常见的 REST API 设计缺陷是在 URL 中包含敏感信息，包括用户凭据、密钥或令牌。

6、严格定义允许的RESTful API请求和响应，开发者负责
— 错误处理
— 应始终考虑对输入进行验证
— 严格管控 REST API 可提供的响应类型。例如，响应应限制为明确允许的内容类型，如 GET、PUT 和 POST。

7、重要ID不透明处理，开发者负责
在系统一些敏感功能上，比如，/user/1123 可获取 id=1123 用户的信息，为了防止字典遍历攻击，可对 id 进行 url62 或者 uuid 处理，这样处理的 id 是唯一的，并且还是字符安全的。

8、速率限制，网关产品可提供
设计良好的API还可以应用速率限制和地理速度检查，以及作为地理围栏和I/O内容验证和消毒等策略的执行点。

9、实施持续API发现功能，避免产生新的安全漏洞，三方产品可提供
分析API日志以获取 API 活动的证据，这将有助于确保您的安全团队了解企业中正在使用的所有 API。

常用身份验证模型

RESTful应用程序依赖于API生态系统的底层安全性，而不是在REST架构风格中包含安全性。除了通过HTTPS协议保护RESTful API调用之外，还应使用基于会话的身份验证。目前，大多数RESTful应用程序利用了OAuth 2.0和Open ID Connect（OIDC）协议。

SAML

安全评估标记语言（SAML）最初由大学设计，以允许其他大学的学生访问图书馆。基于XML和SOAP是原始的联合身份系统。在2000年代初期，当互联网浏览器成为主要客户的时候，SAML被推出。

OAuth 2

OAuth 2创建于2006年，是认证协议的开放标准，通过HTTP提供授权工作流程，并授权设备，服务器，应用程序和API以及访问令牌而不是凭据。 OAuth从Facebook，Google，Microsoft和Twitter的使用中获得了普及，他们允许使用他们的帐户与第三方应用程序或网站共享。

开放ID连接（OIDC）

开放式ID连接（OIDC）扩展了OAuth 2，并将用户信息（身份层）作为请求的一部分。考虑到SAML的现代版本，OIDC允许一系列客户端，包括基于Web的移动设备和使用JavaScript的客户端。

JSON网页令牌（JWT）

JSON Web Token（JWT）是一种用于创建访问令牌的开放标准，用于声明一些声明。使用JSON编写的令牌旨在紧凑 – 专注于使用Web浏览器，单点登录（SSO）上下文。虽然不是身份提供商或服务提供商，但JWT用于在身份和服务提供商之间传递身份验证的用户身份。

RAML

RESTful API建模语言（RAML）是一种旨在描述RESTful API的语言。 RAML是用YAML人类可读的数据串行化语言编写的。 RAML的努力首先在2013年提出，并获得了诸如MuleSoft，AngularJS，Intuit，Box，PayPal，可编程Web和API Web Science，Kin Lane，SOA Software和Cisco等技术领导者的支持。 RAML的目标是提供所有必要的信息来描述RESTful API，从而提供一种更简单的设计API的方法。

参考资料

REST API 面临的 7 大安全威胁
 REST API 安全要点
 API 安全性实践
 API安全成熟度模型
 应用程序接口（API）安全的入门指南，大量基础概念，可以作为清单来用
Web应用风险点有哪些？