什么是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 网关可以验证 ID 令牌等凭据，从而对所有 API 请求的身份进行验证。

• 速率限制和节流。 API 网关安全措施包括限制 API 在特定时间段内的调用次数，以确保不会超出其处理能力或不堪重负。这有助于防范拒绝服务攻击以及暴力破解攻击和试错攻击，在后面这两种攻击中黑客会反复使用各种凭据来尝试访问系统。

• 策略执行。 API 网关可以强制要求 API 在访问微服务和后端服务时遵循各种策略和规则，尤其是与身份验证、授权及访问控制措施相关的策略和规则。

• 基于签名的防护。 API 可以识别出已知攻击的签名和模式，从而拦截一些威胁。

• 日志记录和监控。 API 网关能够持续监控与 API 使用相关的 API 流量和指标。此外，API 网关也可以记录所有事务，方便用户深入了解使用情况和安全问题。

• 分离。 为了增强安全性，API 网关将后端服务与前端应用程序分离，以消除两者之间的任何直接接触。这可以帮助阻止将恶意代码注入后端数据库的 SQL 注入攻击。

API 网关安全的有效性如何？

尽管 API 网关是安全计划中的重要组成部分，但它们仅仅是一层防护机制，因此，仍然存在一些需要应对的安全漏洞。对于 API 网关，失效的对象级授权 (BOLA) 等攻击可能看起来像是正常流量，这会导致系统容易受到 BOLA 和失效对象属性级授权 (BOPLA) 攻击的威胁。此外，API 网关无法对 API 清单进行充分监控，因而无法确保安全团队能够留意到所有 API，也无法确保采取适当的控制措施和策略来保护每个 API。因此，很多企业都将其他 API 保护解决方案与 API 网关搭配使用，以提升对攻击面的监测能力。

API 网关安全的最佳实践有哪些？

企业及其安全团队可通过遵循以下最佳实践来增强 API 网关安全。

• 集中管理身份验证。 一些微服务会尝试独立管理身份验证过程中的访问权限、令牌验证及其他要素，这会导致复杂性增加并带来安全漏洞。通过在网关处集中管理 API 身份验证，企业可以充分地降低每个此类微服务的风险。

• 实施速率限制。 控制 API 请求的数量不仅可以防止过量的恶意或合法请求使服务过载，还能够抵御 DoS 或 DDoS 攻击。

• 持续监控。 持续监控和分析可以帮助检测潜在威胁，并解决客户端访问和请求问题。

• 移除不使用和已弃用的 API。 通过跟踪所有 API 并移除不再使用或不再支持最新安全措施的 API，安全团队可以增强 API 网关安全。

• 启用 Web 应用程序防火墙 (WAF)。 在网络和 API 安全计划中部署 WAF，可以根据已定义的规则和条件来限制对 API 的访问，从而阻止注入攻击和跨站点脚本攻击等常见威胁。

• 利用行为分析。 基于 SaaS 的行为分析解决方案可以记录所有 API 活动，以确定正常行为的基准。然后，它可以对潜在威胁发出告警，并提供防御或主动响应建议。

划重点，如何做？

上文是给入门者的普及知识，那我们带到业务和实际场景里来看看为什么要做API治理，发生的问题到底有多严重。

经常听人说，某某系统被黑了，某某 app 的短信 1 分钟内被狂刷了几万条，某某应用的系统瘫痪了...诸如此类不一而足。追根溯源，从问题分析的经验来看，不管系统攻击者采用何种手段，多数情况下，最终攻击的入口，或者说最终的受害者还是汇聚到了API 这一层，可见，API 可以说是系统的守卫员，不容有失。

API 安全常见问题

 接口被恶意调用

当系统的某些接口被攻击者或别有用心的人恶意调用时，可能有如下表现：

·系统被狂刷短信...

·某个页面直接卡死，导致其他用户无法访问页面...

·系统服务器 CPU 瞬间飙升...

·平台内关联的其他应用也无法正常使用...

为什么 API 接口会被恶意调用呢？经验来看，无非就那点，树大招风，你的产品被竞争对手盯上了，人家眼红了。

接口数据被篡改

这也是一种比较场景的 API 安全问题，一个常见的场景就是，当你登录某个系统时，你的会话信息，像存在浏览器中的 cookie 信息，被别有用心者劫持了，然后这个人拿着你的信息冒充你的身份去请求 API 的数据，甚至修改你的数据返回给你进行诈骗等目的。使用过 Fiddler 抓包工具的同学可以在自己公司的产品中模拟下这个过程。

接口敏感数据被窃取

通常在 B 端产品中，会对某些 API 返回的部分字段数据进行脱敏，比如手机号，邮箱等，以保证用户的信息隐私。

尽管 API 层面对敏感数据做了脱敏处理，但敏感数据如果未进行加密处理，或加密的强度不够，或者没有安全的存储加密数据，以至于攻击者仍然能够获得敏感信息，进而攻击者可能利用此漏洞对客户端，或服务器发送特殊构造的数据，发出攻击，从而了解后台数据库表等信息，对系统安全构成威胁。这也就是接口敏感数据被窃取了。

注：某单位在某省攻防演练，一下扣到负几千分的原因，您找到了吗？需要防护改进，请联系三沐，必须给你安排的明明白白。

XSS 攻击

深究起来，XSS 攻击更多偏向于前端这一层，但是对于一个能够提供充分安全保障的系统来说，API 的对于参数的安全校验也是非常重要的一环，对于系统来说，应该确保核心 API 的业务对于所有的入参都应该是安全，可信且经过校验之后才能进行数据存储的。这样可以从源头上保障 XSS 攻击影响的范围进一步缩小。

系统层面的安全防护解决措施

在系统架构设计之初，系统安全一定是一个重要的考量因素被纳入到架构设计规划中，系统安全关乎着既关乎公司的生存，也关乎产品的盈利，更进一步说，更关乎着法律法规对公司的监管合规性依据。下图所示，为一个通用的微服务业务架构图。

从实践经验来看，安全在一个系统的架构设计中占据着举足轻重的地位，从上图来看，可以说，安全考虑在架构设计的每一环都有着落地的目标，拆开来看，具体如下所述。

前端安全

涉及到前端安全的技术，比如：

· 页面表单的防重提交（功能上限制防刷的可能性）；

· 接口请求前关键参数的校验，脱敏，XSS 不安全字符的自动识别；

· 使用参数加密，Base64 处理，禁止明文传输;

系统级防火墙

防火墙本身具有较强的抗攻击能力，它是提供信息安全服务、实现网络和信息安全的基础设施之一。

防火墙对于一个互联网公司的重要意义毋庸置疑，尤其是金融类，银行类等 B 端产品，防火墙的作用可以说是不可替代的，尽管这个技术已经不是什么新鲜的东西，但基本上所有的软件公司在产品发布到线上环境之后，所有来自外部的请求，都会经过服务器厂商的防火墙，只有通过了防火墙这一层请求才能继续往下进行。

关于防火墙的作用，这里简单列举如下：

·防止来自被保护区域外部的攻击，保护易受攻击的网络服务资源和客户资源；

·集中安全管理，通过集中的安全策略配置，以便统一管理和执行安全政策；

·防止信息外泄和屏蔽有害信息，执行安全检查，严格控制进出网络的数据，过滤和屏蔽有害信息，防止信息外泄；

·安全审计和告警，通过对网络存取访问进行监控审计，有效跟踪各类网络活动，及时发现问题和及时报警。

网关

关于网关，基本上所有的人都多少有一定的了解，网关在一个安全的系统架构设计中的作用，可以说是承上启下，至关重要，大体来说，从安全的角度来讲，主要体现在如下几个方面：

屏蔽真实的API地址

拿 nginx 来说，如果后端的接口真实地址是：/API/v2/user/get/1，为了确保接口安全，屏蔽真实的地址，通过nginx 的反向代理之后，接口可能变成这样：/platform/biz/API/v2/user/get/1。

负载均衡，均衡流量

    从系统安全和系统可用性的角度讲，为了确保系统的高可用性，通常应用服务集群部署，这样可以避免单节点压力过大而造成业务高峰时系统不可用，有了网关这一层，就可以通过网关的配置动态实现负载均衡，以达到均衡流量的效果，从而对系统过载形成防护。

拦截恶意请求，定向黑白名单

    以 nginx 来说，提供了可编程式的配置，通过编写脚本代码，对经过 nginx 的请求进行监控，尤其是对于那些恶意刷接口的请求，可以很好的进行识别，甚至可以在 nginx 这一层对那些恶意请求的 IP，IP 段进行黑名单的设置，从而对后台的服务进行第一层的安全防护。

限流

   对一个系统来说，可用性已然成了系统是否稳定的考量因素的重要标准，当业务高峰期时，不管是外部的恶意请求，还是类似抢单这样的瞬间大流量来说，为了保障系统的整体可用性，必要的限流措施也是确保系统安全的重要手段，而网关作为承载系统流量的入口，在网关这一层做一定的限流管控是很有必要的。

API 层面安全设计的常用解决方案

以上从架构设计层面聊了一下常用的安全防护措施，而作为系统对外提供数据来源的 API 接口，也就是系统的核心后台服务，可以说，关于 API 的安全考虑，可以说很多开发者在设计过程中尚未引起足够的重视。这里小编说一个有意思的现象，在小编过往的工作经历中，那些甲方公司最终对项目进行验收时，通常需要对整个源码进行安全审计，其中审计最容易出问题的地方，就是很多 API 接口的安全问题，比如 XSS 攻击，CSRF 攻击，接口有被刷的风险...

接下来，针对上述谈到的问题，以及日常开发中对于 API 安全的一些规范性要求，一起探讨下在 API 安全设计的一些处理措施。

控制 API 的访问边界

以当下流行的微服务来说，后台提供出去的 API 一定要规范访问边界，哪些接口可以暴露出去，哪些接口一定要通过鉴权才能访问，关于这一点，依照经验来说，做好下面几点即可：

·接口设计之初，与前端同学约定好接口的使用场景；

·对外暴露且不需要鉴权的接口做好流控，避免被刷，比如有些登录接口中需要用到短信验证码的场景；

·对外暴露且不需要鉴权的接口做好严格的参数校验，避免 XSS 字符的入库存储；

·需要走鉴权的接口，最好走统一的安全校验逻辑，比如 SDK 或者内部封装的组件；

严格规范 API 的使用类型

对于某些比较大的平台来说，比如 pass 平台，通常都是十几个甚至几十上百个内部服务组成的，如此庞大的系统统一对外提供服务时，各应用服务之间必然存在着互相的调用，这些可以是 dubbo 调用，或者 http 的调用，通常不同的应用之间调用时，走 rest 接口非常多，同时，不同应用之间互相调用时，场景也是多样，有些需要认证，有些不需要，有些需要严格的认证，有些需要宽容的认证，这该怎么办呢？

针对上面的场景，这里可以考虑定义不同的 API 使用类型，针对不同类型的 API，在调用的时候策略也不一样，具体实践来说，可以参照如下设计原则；

系统外部可调用的 API

这种 API，即内部应用和外部应用都可以调用的 API，这类 API 的设计，通常需要通过一个统一的凭证颁发入口，调用者拿到这个凭证，在调用 API 时传过去，认证通过后，API 给与数据响应，由于凭证是系统内部的服务颁发，可以认为是安全的，同时，如果更进一步的话，可以对凭证做有效期的设定，甚至是加密处理等措施。

系统内部可调用的 API

即平台各个微服务应用之间调用的 API，由于内部的应用在使用之前，都需要一定的注册或者其他的认证措施，对于内部的 API 调用来说，可以在 API 接口中添加关键参数信息识别即可，比如，在请求内部 API 的时候添加一个 appName 这样的标识，一旦 API 校验这个 appName 合法有效，就可以给与响应。

无需认证的 API

比如请求系统的首页，或者上面谈到的请求短信验证码，再就是某些需要对接平台的外部第三方应用，这些第三方应用需要拿到一些非敏感的数据作为业务标识等，这种情况下，针对这样的 API，在设计时，要做好关键参数的校验，接口防刷的处理，以及可信 IP 的识别。

API 敏感参数加密处理

类似于登录，获取用户信息的 API 接口，一定要做加密处理，防止因会话劫持造成数据传输过程中敏感信息的泄露，关于加密，常用的加密方式包括：

·密码的 MD5 加密，甚至可以混合盐值提高加密的安全等级；

·对称或非对称加密（根据业务需要选择）；

·JWT，也是当下流行的一种轻量化的加解密方案；

API 请求 header 中混合特殊参数

一种常见的场景就是，前端请求 API 接口时，需要在请求的 header 中添加后台办法的 token 或者其他的令牌等参数，而请求到达 API 之前（有的在 API 中做），解析并统一校验 API 请求中的 header 是否携带了这个参数，且有效的情况下才予以返回。如果你的 API 安全等级更高，可以考虑在请求 header 中混合其他的定制化参数，这也是一种有效的保护 API 的手段。

API 自身的防刷措施

对于一个成熟稳定的系统来说，尽管请求在真正到达 API 时有各种防护措施，比如限流，恶意请求 IP 识别等统一的措施，但是作为打通数据后台到前台的最后一关，针对系统中的某些核心业务的 API，还是有必要做针对性的接口防刷机制，具体来说，可参考下面的思路进行实施；

·根据来源 IP，核心业务字段的组合进行恶意请求的识别，限制这类请求频次，减少对服务端的压力；

·API 采用限流组件，或者引入开源限流 SDK，或者自己编写限流算法工具包，对热点 API 进行限流；

·日志追踪，针对那些恶意刷接口的 IP，记录在日志，并接入告警平台，定向的上报监控告警；

尽量对请求参数进行封装

一般来说，从 rest 请求安全的角度来说，post 请求的安全性要好于 get 请求，这是因为大多数情况下，get 请求暴露在请求 url 中，而 post 请求的参数相对来说会隐蔽一些。这里给出的建议是，当查询请求参数超过 5 个时，可以对请求参数进行封装，然后将亲请求类型调整为 post。

API 参数校验

为什么这一点放在最后来说，小编认为这是大多数开发者能够想到但在实际工作中又不能做得很好的一点。参数校验可以说是 API 层面最后一道基础但是重要的安全保障了，但是在参数校验这个度的把握上，很多开发人员显得有些不知所措，这里小编提出下面几点建议以供参考：

区分 API 的重要程度

并不是所有的 API 都需要一大堆的参数校验，为什么这么说呢？要知道，参数对于一个系统安全的影响随着链路的传递是逐渐增加的，假如说一段xss的字符作为参数传入到 API 接口中，假如不做处理最终会入库，后面再查询出来渲染到页面时候，这个危害性就大了，影响的不仅是用户的体验，甚至会失去一个潜在的有价值的用户。

说到这里，相信大家能够了解，假如在 save 数据的接口中就能够识别非法参数，从而进行拦截的话，后续所有的麻烦都可以提前避免掉。从这个角度来说，一个通用的做法就是，针对那些需要保存表单的数据，或者是涉及到修改，删除之类的 API，一定要做好参数的校验和控制。

不要过度对参数进行校验

看到过不少开发者在一个存储数据的接口中对参数进行了相当篇幅的代码校验，并不是说这样不好，而是需要区分一个度的问题，举例来说，有人在编写一个保存用户的 API 接口时，对用户名称做校验时，大概有几十行代码，涉及的规则如下：

·校验账户中是否有特殊字符，比如$% 这样的字符；

·校验账户名称长度是否超过限制；

·校验系统中是否有重复的账户名；

·校验账户名中是否有违禁的词；

·校验账户名中是否有多音字；

·...

我就想不通了，一个账户名的校验需要搞那么多花样吗，开个玩笑，这当然不是我的过激行为，我要表达的意思是，API 设计时，在考虑安全性的同时尽可能兼顾使用者的习惯，简化因参数校验带来的交互流程上的麻烦。

说这么多防护细节，有没有高效直接的？

有，肯定有，有开源和商业化的解决方案，具体详情希望感兴趣或者有治理需求的朋友，后台留言，或者文章留言，根据情况看是否分享对应的解决方案。

欢迎关注“三沐数安”，请分享给更多的网安爱好者，大家一起研究网络安全技术。三沐专注于数据安全建设和网络安全建设，解决您身边的网络安全问题，成为您的安全好帮手。

原文始发于微信公众号（三沐数安）：什么是API 安全？如何做好API数据安全的防护？