1.什么是API
API(Application Programming Interface,应用程序编程接口)是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件的以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。通过淘宝API，就算不知道如何操作，也能将产品或服务与其他产品或服务进行互通。这样就可以简化应用开发，节省时间和成本。API除了有应用“应用程序接口”的意思外，还特指 API的说明文档，也称为帮助文档。
API作为应用编程接口，由应用程序来调用，提供API的称为提供者，使用API的称为消费者。API本质上是一个程序(程序1)中，专门用于与其他应用程序(程序2)进行交互的部分，也就是程序1的外部对接部门。程序员所编写的程序2可以通过API程序的函数声明来和程序1进行交互。API 由一个或多个方法组成，每个方法可以实现一个功能，比如发送消息，上传文件，检索消息等。
定义和作用看起来有些晦涩难懂，我们可以类比一个常见且熟悉的接口User Interface（缩写为 UI）即用户接口。UI本质上是一个系统中专门用于与人类使用者进行交互的部分。UI可以是一个实物上的面板，也可以是由程序所驱动的显示在屏幕上的界面。我们使用的应用一般有是图形化界面的，都可以看作是一种用户接口，比如按钮，窗口，图标等可视化组件。UI 定义了人与应用程序进行交互的方式。UI 由多个可视化组件构成，每个组件提供不同的交互方式，比如，在文本框中可以输入一些消息，点击按钮可以发送消息等。
总之，API定义了应用程序与应用程序之间的交互，UI定义了人与应用程序之间的交互，并且两种交互方式又相互关联，用户操作 UI 表达要实现的功能，而 UI 使用 API 来实际完成该功能。
2.API的分类
（1）根据API提供者和消费者所在的位置，可将API分为两类：本地API：当API的提供者和消费者位于同一台计算机上时，称为本地API。远程API：当API的提供者和消费者位于不同的计算机上时，称为远程API。
（2）根据API接口表现形式分类：
| 接口 | 协议 | 说明 |
| HTTP接口 | HTTP | 当发起Http请求时，Http会通过TCP建立起一个到服务器的连接通道，在请求需要的数据完毕后，Http会立即将TCP连接断开，Http连接是一种短连接、无状态的连接。 |
| RPC接口 | HTTP、TCP、UDP、自定义协议 | RPC远程过程调用协议，它本质上是一种Client/Server模式，就相当于调用本地接口一样调用远程服务的接口，支持多种数据传输方式，如Json、XML、Binary等。 |
| WebService接口 | SOAP协议通过XML封装数据，Http协议传输数据 | WebService是一个应用程序向外界暴露出一个能通过Web进行调用的API，也就是系统对外的接口，使用XML来封装数据，不依赖于语言，不依赖于平台。 |
| RESTFUL | HTTP | RESTFUL一种设计准则，而不是一种规范，用不同的HTTP动词(如：GET、POST、DELETE、PUT)来表达不同的请求，降低开发的复杂性，提高系统的可伸缩性。 |
| WebSocket | TCP、UDP | WebSocket是一个持久化的双向通信协议，可实现客户端和服务器端之间即时通讯。在WebSocket中，客户端和服务器只需要完成一次握手，就可以创建持久性的连接，并进行双向数据传输。 |
| FTP | TCP/IP协议组中的协议之一 | FTP是文件传输协议，FTP协议包括两个组成部分，其一为FTP服务器(存储文件)，其二为FTP客户端。 |
（3）根据API接口访问形式分类：
| 访问形式 | 说明 | 应用 |
| 使用用户令牌，通过Web API接口进行数据访问 | 可以有效识别用户的身份，为用户接口返回用户相关的数据。 | 用户信息维护、密码修改、用户管理等与用户信息相关的数据 |
| 使用安全签名进行数据提交 | 这种方式提交的数据，URL连接的签名参数是经过安全一定规则的加密的，服务器收到数据后也经过同样规则的安全加密，确认数据没有被中途篡改后，再进行数据修改处理。可以为不同接入方式(Web/APP/Winfrom等)，指定不同的加密秘钥，秘钥是双方约定的，并不在网络连接上传输，连接传输的一般是这个接入的AppID，服务器通过这个AppID来进行签名参数的加密对比，微信后台的回调处理机制就类似于这种处理方式。 | 获取令牌、用户注册、处理业务数据等 |
| 提供公开的接口调用，不需要传入用户令牌、或者对参数进行加密签名 | 这种接口一般较少，只是提供一些很常规的数据显示而已。 | 查询系统版本、时间、天气等数据 |
3.API安全
API安全基于多种安全规则的交叉，如下图所示。
API安全的目标（CIA）：
安全目标用于定义安全对于保护资产的实际意义。安全没有统一的定义，有些场景中的定义可能是冲突的。从系统正确运行时希望达到或保持的安全目标出发，可以拆分安全目标。一些标准的安全目标几乎适用于所有的系统，其中最著名的是“CIA三元组”：
机密性（Confientiality）：确保信息只被预期的读者访问；
完整性（Integrity）：防止未授权的创建，修改和删除；
可用性（Availability）：当用户需要访问API时，API总是可用的。
这三条原则始终很重要，在其他情景中，有一些原则和以上三条一样重要。比如accountability/可追责（谁做了什么）或者non-repudiation/抗抵赖（不能否认做过的行为）等。
常见的API风险（STRIDE）:
欺骗（Spoofing）：伪装成某人；
干预（Tampering）：将不希望被修改的数据、消息或设置改掉；
否认（Repudiation）：拒绝承认做过的事；
信息泄露（Information disclosure）：将你希望保密的信息披露出来；
拒绝服务（Denial of service）：阻止用户访问信息和服务；
越权（Elevation ofprivilege）：做了你不希望他能做的事。
风险与安全机制的对应关系：
认证=>欺骗：确保你的用户或客户端真的是他（它）们自己 ；
授权=>信息泄漏/干预/越权：确保每个针对API的访问都是经过授权的；
审计=>否认：确保所有的操作都被记录，以便追溯和监控；
流控=>拒绝服务：防止用户请求淹没你的API；
加密=>信息泄漏：确保出入API的数据是私密的。
4.API安全威胁
OWASP API 安全性十大威胁：
对象级别授权中断：对于未使用适当级别的授权保护的 API 对象，可能会因为较弱的对象访问标识符而容易发生数据泄漏和未经授权的数据操作。例如，攻击者可以利用一个可迭代的整数对象标识符。
用户身份验证中断：身份验证机制的实现通常不正确或缺失，使得攻击者可以利用实现缺陷来访问数据。
过多的数据暴露：恶意行动者会试图直接访问 API（可能通过重播有效请求），或者嗅探服务器和 API 之间的流量。对 API 操作和可用数据的分析可能会为攻击者生成敏感数据，而这些敏感数据并没有展示在前端应用程序中，也没有被前端应用程序使用。
缺少资源和速率限制：缺少速率限制可能会导致数据外泄或对后端服务的成功 DDoS 攻击，进而导致所有使用者的服务中断。
功能级别授权中断：具有不同层次结构、组和角色的复杂访问控制策略，以及管理功能和常规功能之间不明确的分离，都会导致授权缺陷。通过利用这些问题，攻击者可以访问其他用户的资源或管理功能。
大量分配：如果一个 API 提供的字段超过了客户端对给定操作的需求，攻击者可能会注入过多的属性来对数据执行未经授权的操作。攻击者可以通过检查请求和响应或其他 API 的格式来发现未记录的属性，或进行猜测。如果你不使用强类型的编程语言，则此漏洞尤其适用。
安全配置错误：攻击者可能会试图利用安全配置错误漏洞，例如：缺少安全强化措施、启用了不必要的功能、不必要地向 Internet 开放了网络连接、使用了弱协议或密码、可能允许未经授权地访问系统的其他设置或终结点。
注入：接受用户数据的任何终结点都可能会受到注入攻击。示例包括但不限于：命令注入，其中恶意行动者试图更改 API 请求以在托管 API 的操作系统上执行命令；SQL 注入，其中恶意行动者试图更改 API 请求以针对 API 依赖的数据库执行命令和查询。
资产管理不当：与不当的资产管理相关的漏洞包括：缺少适当的 API 文档或所有权信息、旧版 API 过多，可能缺少安全修补程序。
日志记录和监视不足：如果日志记录和监视不足，加上与事件响应的整合缺失或无效，攻击者就能够进一步攻击系统、保持持久性、转向更多系统进行篡改，以及提取或销毁数据。大多数违反行为研究表明，检测到违反行为的时间超过 200 天，通常是由外部方而不是通过内部流程或监视方式检测到的。
5.API协议
SOAP：简单对象访问协议（Simple Object Access Protocol，SOAP），它是广泛使用的最古老的以 Web 为中心的 API 协议。SOAP 于 1990 年代后期推出，是最早设计用于允许不同应用程序或服务使用网络连接以系统方式共享资源的协议之一。SOAP 代表简单对象访问协议，是一种基于 XML 的消息传递与通信协议。必须创建 XML 文档才能进行调用，而 SOAP 所需的 XML 格式并不完全直观。这就会使得调用和调试变得困难，因为调试需要解析长字符串的复杂数据。另一方面，SOAP 依赖于标准协议，尤其是 HTTP 和 SMTP，并为 Web 服务提供数据传输。SOAP 的整个消息都是被写在 XML 中的，因此它能够独立于各种语言在所有操作系统上都可用。
REST：表述性状态传递（Representational State Transfer），由Roy Fielding在2000年的一篇论文中引入，其目标是解决SOAP的一些缺点。REST是基于 HTTP 协议的 Web 标准架构，REST相比于SOAP更灵活，因为它支持多种数据格式，而不需要 XML。遵循REST架构约束的Web API 被称为RESTful API。对于开发人员来说，RESTful 架构是理解 API 功能和行为的最简单工具之一。它不但能够使得 API 架构易于维护和扩展，而且方便了内、外部开发人员去访问 API。REST与SOAP又有着根本的区别，SOAP是一种协议，而REST是一种架构模式。这意味着RESTful Web API没有官方标准。只要API 符合RESTful系统的6个导向性约束，就算作RESTful API：客户端/服务器架构、无状态、可缓存性、分层系统、统一接口、按需代码（可选）。
JSON-RPC：JSON-RPC，是一个无状态且轻量级的远程过程调用（RPC）传送协议，其传递内容透过 JSON 为主。相较于一般的 REST 透过网址（如 GET /user）调用远程服务器，JSON-RPC 直接在内容中定义了欲调用的函数名称（如 {"method": "getUser"}），这也令开发者不会陷于该使用 PUT 或者 PATCH 的问题之中。
gRPC：gRPC 是一个开源 API，也属于 RPC 的范畴，是一个高性能，开源和通用的RPC框架，基于Protobuf序列化协议开发，且支持众多开发语言。面向服务端和协议端，基于http/2设计，带来诸如双向流，流控，头部压缩，单TCP连接上的多路复用请求等特性。这些特性使得其在移动设备上表现的更好，更省电和节省空间。在gPRC里客户端可以向调用本地对象一样直接调用另一台不同机器上服务端应用的方法，使得您能够更容易地创建分布式应用和服务。
