API安全性的最佳实践:全面指南!

应用程序编程接口 (API) 是在线存储和共享信息的标准方式。这些虚拟数据库通过数据访问为网站和其他应用程序提供增强的功能。许多企业依赖 API 来存储有关客户和消费者的信息。虽然 API 可以轻松调用和修改信息，但任何敏感数据的存储工具都必须是安全的。

API安全是企业为确保数据库中的信息安全而采取的一切措施。安全措施包括定期评估 API 结构、限制请求和建立用户授权级别。

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

集中管理身份验证。 一些微服务会尝试独立管理身份验证过程中的访问权限、令牌验证及其他要素，这会导致复杂性增加并带来安全漏洞。通过在网关处集中管理 API 身份验证，企业可以充分地降低每个此类微服务的风险。
实施速率限制。 控制 API 请求的数量不仅可以防止过量的恶意或合法请求使服务过载，还能够抵御 DoS 或 DDoS 攻击。
持续监控。 持续监控和分析可以帮助检测潜在威胁，并解决客户端访问和请求问题。
移除不使用和已弃用的 API。 通过跟踪所有 API 并移除不再使用或不再支持最新安全措施的 API，安全团队可以增强 API 安全。
启用 Web 应用程序防火墙 (WAF)。 在网络和 API 安全计划中部署 WAF，可以根据已定义的规则和条件来限制对 API 的访问，从而阻止注入攻击和跨站点脚本攻击等常见威胁。
利用行为分析。 基于 SaaS 的行为分析解决方案可以记录所有 API 活动，以确定正常行为的基准。然后，它可以对潜在威胁发出告警，并提供防御或主动响应建议。

API安全常见问题：

接口被恶意调用

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

·系统被狂刷短信…

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

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

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

接口数据被篡改

这也是一种比较场景的 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 的访问边界必须规范：

接口设计之初，与前端开发者约定接口的使用场景。
对外暴露的无需鉴权接口，需要做好流量控制（流控），防止被刷，如登录接口中使用短信验证码的场景。
无需鉴权的对外接口，应进行严格的参数校验，防止 XSS 字符存储。
需要鉴权的接口，最好采用统一的安全校验逻辑，如使用 SDK 或内部封装的组件。

严格规范 API 的使用类型

针对大平台，如 PaaS 平台，其由多个内部服务组成，这些服务之间的调用（如 Dubbo 或 HTTP 调用）需要规范：

系统外部可调用的 API：需要通过统一的凭证颁发入口，调用者通过凭证验证后才能获取响应，凭证可设有效期或加密。
系统内部可调用的 API：内部应用间调用时，通过添加如 appName 这样的标识进行认证。
无需认证的 API：如首页请求或获取短信验证码，应做好参数校验、防刷处理及可信 IP 识别。

API 敏感参数加密处理

对于登录、获取用户信息等接口，需加密处理以防会话劫持：

密码的 MD5 加密（可加盐提高安全性）。
对称或非对称加密，根据业务需要选择。
使用 JWT 进行轻量级的加解密。

API 请求 header 中混合特殊参数

前端请求时，在 header 中添加 token 等参数，进行统一校验。更高级的安全可以混合定制化参数。

API 自身的防刷措施

即使有统一的防护措施，对核心业务 API 仍需额外防刷：

通过 IP 和业务关键字段组合识别恶意请求，限制频次。
使用限流组件或 SDK 对热点 API 进行流量控制。
日志跟踪并接入告警系统，监控恶意请求。

尽量对请求参数进行封装

从安全角度，POST 请求比 GET 请求安全，建议当查询参数超过5个时，封装参数并使用 POST 请求。

API 参数校验

虽然是基础，但参数校验是 API 安全的最后保障：

区分 API 的重要程度：不是所有 API 都需要复杂的参数校验，特别是涉及数据保存、修改或删除的接口。
不要过度校验：在某些接口中，过多的参数校验可能不是必要的，应根据实际需求来决定校验的程度。