2023年10月30日13:42:35

API的发展历程

在应用程序开发过程中，API 是一个会被经常提及的东西，它的全称是 Application Programming Interface（应用程序接口），一般指的是 Web API，即：采用 HTTP 通信协议的 API 或者是 Web 应用程序对外提供的 API。通过API，企业一方以特定方式发送远程请求，无需了解对方内部系统的逻辑，即可访问对方开放的资源，实现企业内外部产品和服务的互动，资源即服务，API已成为企业内外部系统集成的重要手段。 并且随着互联网的发展，API成为了一种新的商业理念，通过API快速构建产品和服务，迅速响应客户需求，API经济应运而生。

API的发展历程是从单体架构走向微服务架构的过程。

单体架构（Monolithic Architecture） 和微服务架构（Microservices Architecture） 是构建应用程序和产品的两种不同方式，每种方式都有自己的优点和缺点。

在云技术与容器技术兴起之前，单体架构一直是构建应用程序的主流架构，然而这两种技术的兴起，为企业快速部署项目以及持续集成带来了很大便利。随着容器技术与云技术的发展，微服务已成为高速增长公司中构建应用程序的首选。

在微服务架构中，有一个组件可以说是必不可少的，那就是API网关，API网关处理了负载均衡，缓存，路由，访问控制，服务代理，监控，日志等事情， 让企业不需要每个后端服务都重复写鉴权模块、统计模块、限流模块等，重复的功能模块交给网关去做，企业只需要专注逻辑业务即可。API网关还可以为外部消费者提供统一的入口点，而与内部微服务的数量和组成无关。

单体架构会带来以下问题：

• 业务逻辑捆绑在一起，随着代码库变得越来越大，开发人员在编译和部署的时间上明显增多。

• 随着项目越变越大，引用的技术越来越多，由于技术的不兼容性，想要继续在单体架构上拓展功能，就存在对某些功能在技术选型上进行妥协的情况，不得不放弃最合适的技术。

• 庞大的代码库会给新加入的成员带来很大压力，无法让他们在短时间内快速上手工作，并且新人贡献的代码也会增加应用的出错几率。

解决上述问题的办法就是使架构微服务化， 微服务在构建时已实现了业务的隔离和可伸缩。微服务化会带来以下便利：

• 功能组件化开发使团队能够独立的进行迭代和部署。

• 微服务的设计拥有应对故障的能力，涉及到冗余和隔离，使应用程序更加健壮。如果一个服务发生故障，其他服务仍是正常运行，不会导致整个应用程序崩溃。如果服务突然经历请求的增加或减少，则可以在不影响其他服务的情况下水平增加或减少。

• 提高开发效率，相比于单体应用，微服务对项目后期发展拥有更好的效率保证。

• 可以根据业务特性选择最合适的技术，使功能得以快速实现。

从内部系统集成到开放平台，API从1.0时代步入3.0时代。

API1.0单体架构时代（内部服务调用）

API服务的发展历程也可以看做企业数字化过程中系统集成需求不断变化的过程。初期随ERP、CRM等企业内部管理系统的普及，各类系统沉淀了海量的关联数据，基于早期的数据库和http1.0通信协议，API开始在企业内部数据打通展露头角，系统集成进入API1.0时代。

优点： 单体应用直接使用分层结构，业务逻辑的实现有着清晰的IT结构。

缺点： 调用关系复杂，存在重复调用，影响整体服务进程。

API2.0 SOA架构时代（面向服务的架构）

2007年前后，随web2.0时代到来，企业信息和资源跨出企业内部，各企业系统不再是孤立状态，系统资源和数据的整合需求也扩散至外部，进而出现了UDDI技术规范和基于SOAP协议的API接口，系统集成入API2.0时代。

UDDI是一种用于描述、发现、集成Web Service的技术，它是Web Service协议栈的一个重要部分。通过UDDI，企业可以根据自己的需要动态查找并使用Web服务，也可以将自己的Web服务动态地发布到UDDI注册中心，供其他用户使用。UDDI API。UDDI API是一组用于查找或发布UDDI数据的方法，UDDI API基于SOAP。

SOAP（Simple Object Access Protocol）简单对象访问协议。它是轻型协议，用于分散的、分布式计算环境中交换信息。SOAP有助于以独立于平台的方式访问对象、服务和服务器。

优点： 提出服务重用和消息总线概念，一定程度上避免了重复调用的情况。

缺点： 集中化的总线部署，导致后期运维升级困难，不符合灵活敏捷的架构需求。

API3.0 REST架构时代（开放平台）

2015年后，云服务主导了企业服务市场，大型企业在内部系统集成理顺的基础上，将企业核心资源以带有适当安全和监管措施的“API+云服务”形式向合作伙伴、客户、乃至普通大众输出。

近年来，随着移动技术的发展，各种移动端设备层出不穷，RESTful可以通过一套统一的接口为 Web，iOS和Android提供服务。另外对于广大平台来说，比如新浪微博开放平台，微信公共平台等，它们不需要有显式的前端，只需要一套提供服务的接口，于是RESTful更是它们最好的选择。而基于REST构建的API就是RestfulAPI。

基于此，RESTful API开始被大量应用，API服务正式步入3.0时代。API3.0时代，客户和普通大众可以利用企业通过API输出的资源来完成各自的产品和服务的开发，最终延伸出庞大的价值链。

例如，一套产品溯源查询系统，客户需要在PC端可以访问，APP端可以访问，小程序端可以访问。客户已有追溯码，分别在这三个平台查询该追溯码的真伪，传统的方式，需要写三个接口了，采用Restful api，我们只需要写一个接口即可，三处平台各自调用即可，接口返回的数据各自可以按各自的需要进行渲染。
优点： 分布式框架，可灵活调用、敏捷部署。

缺点： 数据安全性降低。

API设计的特点

API威胁与治理挑战

2019年，OWASP首次发布了API Security Top 10，后来随着API应用的发展和安全实践的深化，OWASP于2023年正式发布了API Security Top 10的内容更新，对API身份认证和授权的管理进行了重点突出（占了Top5中的4个）；此外，自动化威胁防护缺失和API供应链安全风险等也被首次加入到了清单中。

从技术上看，API安全问题很大一部分都属于常规WEB应用安全的范畴。但是在API的场景中，有一部分安全漏洞更容易产生，具有更高的威胁性。

在进行API治理过程中，除了技术角度的评估，还需对API的整个生命周期进行分析，明确API治理的必要性与治理目标。

在API的设计方式上，当下API主流设计形式主要有两类：先设计后研发的线下编写模式、文档代码一体化的代码驱动模式。编写线下文档是目前最常见的 API 设计管理方式，一般通过 Excel、Word 等进行 API 设计管理，存储在 Svn、Git、Confluence 等位置。虽然简单，但是弊端也很明显：

• API 文档模板风格难以统一；
• 难以检查 API 接口设计落地情况；
• 难以进行 API 维护（修改、删除）与统计；
• 管理严重依赖管理者，文档位置容易遗忘、人员轮换后难以维护；
• API 文档需线下传阅，共享困难。

常见的 API 文档自动生成工具有 Swagger 与 JavaDoc 等。通过工具生成的 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的全生命周期，及时发现已下线的API。在日志平台监测每一个API的调用量，自动发现调用量在下降的API，就可以及时发现需要下线的API。

API攻击防护

API在实际生产环境中面对的威胁与常规WEB威胁类似，通常需要解决：

• 流量风险：对于异常的请求进行及时的告警和阻断。
• 入侵风险：智能识别 API 运行过程中的攻击入侵行为，识别API可能存在的漏洞。
• 业务风险：智能识别机器人爬虫，防止业务数据被恶意拖取；同时可对API进行规范化管理，避免因为研发规范缺失而导致的业务风险。
• 数据风险：根据API请求进行数据分析，找出API可能存在数据泄漏的情况。

除了使用常规的WEB攻击防御方案，还可以通过OPENAPI规范定义API的格式，在API网关或者WAF产品中校验每个请求的格式，拦截不合法的请求。这实际上是对参数进行白名单校验。可以解决大部分WEB攻击。
编写API的格式文件是个较为麻烦的事情，现在也有部分WAF产品支持自动学习并生成每个API的参数格式，但这需要积累一段时间的流量数据才可以，并且还需要API被调用过。实际场景中这个方法有一定的效果，但误拦截的情况也无法解决，比如学习好的API请求格式在变更后，可能导致误拦截，没办法在生产环节大规模使用。

API日志常态审计

API的威胁检测极度依赖对访问日志的分析，不管是一次登录行为、无权限拒绝访问，还是简单的访问详情页邓星为，都可以被用于分析账号的异常表现，在应用中应当记录完整的访问日志，而且对这些日志需要格式化存储，以便其他安全组件消费。需要额外注意的是，在日志中要避免记录敏感数据。

使用API网关

如果企业有大量的API供外部调用，而且这些API是不同团队开发的，就很难保证相同的安全水平。为了规范API并提供统一的安全防护，通常会使用API网关。
所有的API都通过一个网关向外提供服务，所以不管是攻击防护、身份认证、数据通信加密、威胁检测，都可以在API网关上实现，降低安全策略的实施成本，而且可以保证所有的API安全水平一致。
通常，API网关会叠加WAF功能，当出现新的安全漏洞时可以做到快速的应急响应，添加新的防御规则实现全局防御。针对特定的API安全策略，如限速、限制源IP地址等，都可以通过API网关实现，而无需在应用中对所有API实现相应的功能。

开发安全的 API 所需要核对的清单

以下是当你在设计，测试以及发布你的 API 的时候所需要核对的重要安全措施。

身份认证

• 不要使用 Basic Auth ，请使用标准的认证协议（如 JWT，OAuth）。
• 不要重新实现 Authentication、token generating 和 password storing，请使用标准库。
• 限制密码错误尝试次数，并且增加账号冻结功能。
• 加密所有的敏感数据。

JWT（JSON Web Token）

• 使用随机复杂的密钥（JWT Secret）以增加暴力破解的难度。
• 不要在请求体中直接提取数据，要对数据进行加密（HS256 或 RS256）。
• 使 token 的过期时间尽量的短（TTL，RTTL）。
• 不要在 JWT 的请求体中存放敏感数据，因为它是可解码的。
• 避免存储过多的数据。 JWT 通常在标头中共享，并且它们有大小限制。

访问

• 限制流量来防止 DDoS 攻击和暴力攻击。
• 在服务端使用 HTTPS 协议来防止 MITM （中间人攻击）。
• 使用 HSTS 协议防止 SSL Strip 攻击。
• 关闭目录列表。
• 对于私有 API，仅允许从列入白名单的 IP/主机进行访问。

Authorization

OAuth 授权或认证协议

• 始终在后台验证 redirect_uri，只允许白名单的 URL。
• 始终在授权时使用有效期较短的授权码（code）而不是令牌（access_token）（不允许 response_type=token）。
• 使用随机哈希数的 state 参数来防止跨站请求伪造（CSRF）。
• 对不同的应用分别定义默认的作用域和各自有效的作用域参数。

输入

• 使用与操作相符的 HTTP 操作函数，GET（读取)，POST（创建），PUT（替换/更新） 以及 DELETE（删除记录），如果请求的方法不适用于请求的资源则返回 405 Method Not Allowed。
• 在请求头中的 content-type 字段使用内容验证来只允许支持的格式（如 application/xml，application/json 等等）并在不满足条件的时候返回 406 Not Acceptable。
• 验证 content-type 中申明的编码和你收到正文编码一致（如 application/x-www-form-urlencoded，multipart/form-data，application/json 等等）。
• 验证用户输入来避免一些普通的易受攻击缺陷（如 XSS，SQL-注入，远程代码执行 等等）。
• 不要在 URL 中使用任何敏感的数据（credentials，Passwords，security tokens，or API keys），而是使用标准的认证请求头。
• 仅使用服务器端加密。
• 使用一个 API Gateway 服务来启用缓存、限制访问速率（如 Quota，Spike Arrest，Concurrent Rate Limit）以及动态地部署 APIs resources。

处理

• 检查是否所有的接口都包含必要都身份认证，以避免被破坏了的认证体系。
• 避免使用特有的资源 id。使用 /me/orders 替代 /user/654321/orders。
• 使用 UUID 代替自增长的 id。
• 如果需要解析 XML 文件，确保实体解析（entity parsing）是关闭的以避免 XXE 攻击。
• 如果需要解析 XML 文件，确保实体扩展（entity expansion）是关闭的以避免通过指数实体扩展攻击实现的 Billion Laughs/XML bomb。
• 在文件上传中使用 CDN。
• 如果数据处理量很大，尽可能使用队列或者 Workers 在后台处理来避免阻塞请求，从而快速响应客户端。
• 不要忘了把 DEBUG 模式关掉。
• 可用时使用不可执行的堆栈。

输出

• 增加请求返回头 X-Content-Type-Options: nosniff。
• 增加请求返回头 X-Frame-Options: deny。
• 增加请求返回头 Content-Security-Policy: default-src 'none'。
• 删除请求返回中的指纹头 - X-Powered-By，Server，X-AspNet-Version 等等。
• 在响应中遵循请求的 content-type，如果你的请求类型是 application/json 那么你返回的 content-type 就是 application/json。
• 不要返回敏感的数据，如 credentials，Passwords，security tokens。
• 给请求返回使用合理的 HTTP 响应代码。（如 200 OK，400 Bad Request，401 Unauthorized，405 Method Not Allowed 等等）。

持续集成和持续部署

• 使用单元测试以及集成测试的覆盖率来保障你的设计和实现。
• 引入代码审查流程，禁止私自合并代码。
• 在推送到生产环境之前确保服务的所有组件都用杀毒软件静态地扫描过，包括第三方库和其它依赖。
• 对您的代码持续运行安全测试（静态/动态分析）。
• 检查您的依赖项（软件和操作系统）是否存在已知漏洞。
• 为部署设计一个回滚方案。

监控

• 对所有服务和组件使用集中式登录。
• 使用代理来监控所有流量、错误、请求和响应。
• 使用短信，Slack，电子邮件，电报，Kibana, Cloudwatch等提醒。
• 确保你没有记录任何敏感数据，如信用卡、密码、pin等。
• 使用IDS和/或IPS系统监视您的API请求和实例。

参考链接：
OWASP API
聊聊 API 安全的重要性及治理思路
白帽子讲web安全2