API安全设计的12+个要点

原文和灵感来自ByteByteGo，本文笔者主要将其整理和记述作为知识积累和技术检查单使用，并增加了自己的一些看法和观点。

概述

ByteByteGo有一篇博文，总结了设计和实现一个安全的Web API应用的12个要点，笔者深以为是。这个清单的主要内容如下：

《Top 12 Tips for API Security》

• Use HTTPS
• Input Validation
• Use OAuth2
• Use WebAuthn
• Use Leveled API Keys
• Authorization
• Rate Limiting
• API Versioning
• Whitelisting
• Check OWASP API Security Risks
• Use API Gateway
• Error Handling

本文后面的主要内容将会基于这个清单，进行进一步的分析和说明。

基本原则

在正式开始之前，笔者在这里想要先来总结并强调一下，对于信息系统安全，我们应当持有的正确认知，和建构一个安全的信息系统应当秉持的一些基本原则：

• 科学务实

信息安全是重要的，但对于绝大多数常规的应用场景而言，应该还没有重要到只剩下安全的程度，否则，所有的信息系统和互联网应用应当是没有机会能够发展起来的。另外，安全也不是无代价的，相反，信息安全的代价可能会非常高昂，这些代价会体现在额外的软硬件系统，对应用系统的影响，昂贵的安全软件和人才，时间和延误成本等等。在此就必须秉持一种科学客观的态度，既不夸大安全和损失的风险，也不迷信安全技术实施的效果，而是在完善信息安全认知和基础知识的基础之上，合理评估安全技术和实施方案，找到安全技术选择、实现的可行性、风险和成本之间的平衡。

• 动态过程

信息系统安全，永远是一个动态的过程，任何信息系统相关的设计和实现，都应当考虑和保证这个过程是可以变更、发展和演进的。开发、运营和使用各方，也都应该在这个过程中，持续的实施、检查、优化各项信息安全技术和措施，来保证信息系统能够长期持久稳定的提供服务和业务价值。

• 默认安全

当前的互联网和信息技术的应用环境，已经和几十年前的状况完全不同了。因为它已经越来越庞大，越来越重要，商业和社会价值越来越大，并且已经成为这个世界的重要基础设施。所以，信息系统安全已经成为一项基础工作，而非可有可无的选项。所有的信息技术的系统和软件，都必须在设计和实现的时候，就考虑到信息安全的因素，这体现在开发、部署和运营时，默认情况下就是一种安全的状态，比如初始默认的用户名和密码的安全、防火墙开启、默认严格的文件访问授权、应用程序白名单、API默认拒绝访问等等。这样可以避免一些由于懒惰和配置不当导致的系统安全问题。

• 纵深防御

和所有的防御系统一样，构建多层次、有纵深的防御系统，是一个非常有效的策略。理解这个问题，我们可以并且应该从攻击者的角度出发，多层次甚至不同类型的防御体系，对于发动攻击是非常不利的，因为需要不断的调整和组合不同的攻击的方式、策略和工具，这样的过程是缓慢的，代价是高昂的。如果没有很高的必要性和极大的收益，可能大概率会选择放弃。

纵深防御实现经典的案例就是多因子验证，现在已经逐渐成为一种主流的用户验证的技术方案。

• 最小界面

攻击一头大象，显然会比攻击一只麻雀要更容易。和攻击者对抗过程中，应当尽量减少被攻击面，来达到减少被攻击的可能性的目的。减少攻击面的一个典型做法，就是尽量简化系统，在单个系统上尽量减少在上面运行的应用程序和暴露的网络端口，减少除必要的程序之外的软件和程序，在输出或者响应内容中，并减少除有必要的信息之外的其他信息。

在理解了上述的信息安全和系统的一些主要必要认知和设计原则之后，我们下面就来具体讨论本文的主题： Web API安全设计的要点。

HTTPS

经验和实践证明，HTTPS是Web应用安全的基石。在评估和很多Web应用安全方案和技术之后，我们会很惊讶的发现，虽然需要引入证书管理、DNS、Web服务适配等额外工作，随着生态的完善和成熟，HTTPS确实是最简单、最经济、最开放、最通用，理论和实践安全效果最显著的技术方案。很多原来在HTTP时代面临的安全威胁，在HTTPS时代都被消弭无形。

笔者分析这个情况的主要原因，就是HTTPS不仅仅是对于网络信息进行加密传输，而是从极大的程度上，杜绝了攻击者对网络流量和业务数据的收集和业务分析的可能，让攻击前的准备工作无从开展和入手，相当于在源头上就建立了一个很好的防护体系和屏障，为后面的安全工作打下了一个坚实的基础。

Error Handling 错误处理

在Web应用程序当中，所有的异常都应当得到适当的处理。因为这里需要考虑以下的理由和状况：

• 系统健康和稳定性

有些比较严重的错误或者异常，可能会直接导致应用程序异常退出，系统和服务中断。有些情况下，即使程序没有直接退出，也会由于需要对错误进行处理，导致系统运行缓慢，系统资源占用无法有效释放和回收。也会影响系统的长期稳定可靠运行。

• 信息泄露

有一些不适当的错误处理，可能会导致程序错误时，泄露一些系统和敏感的信息，典型的就是服务器的技术结构、系统配置信息、应用程序代码路径、数据库连接信息、代码片段、引用的程序库等等。这些信息可能会被攻击者用于进行系统分析和进一步的攻击。合理的错误处理，应当只返回对用户有意义的、经过处理而且无风险的信息。

• 数据和系统完整性

错误处理的第一要义在于错误发生时，要保证现有业务和数据的完整性，典型的设计就是关系型数据库的事务机制；然后就是尽量保证服务不中断，不影响其他用户或者系统的正常使用；还应该能够防止应用程序和所在系统进入不安全和不可恢复的状态；最后就是可恢复性，能够在错误发生后，可以有能力自动恢复到正常状态。

• 抵抗拒绝服务攻击

不当的错误处理，例如处理过程存在漏洞或者处理效率低下，可能会放大拒绝服务攻击的效果。让DOS攻击不需要很高的强度，就可以造成大量的系统的资源消耗、错误信息日志洪水等，很快就能够瘫痪系统。更健壮的错误处理，可以提升抵抗此类攻击的能力，降低攻击成功的概率和影响范围。

• 逻辑缺陷漏洞

不当的错误处理操作，可能会导致代码逻辑错误和缺陷，从而被攻击者利用，引入如缓冲区溢出、竞态条件等安全隐患和漏洞。规范和一致的错误处理，有助于有效的避免和弥补这些问题。

• 安全审计

合理而一致的错误处理机制有利于记录和分析安全事件，为事后审计和修复提供信息和依据。相反的，不当的错误处理，可能会产生很多混乱的错误信息，将大大增加审计和故障诊断的难度。

可以看到，错误处理贯穿软件开发和运行的各个环节，直接关系到系统的可靠性、可用性和安全性，将其视为信息安全的重要一环是完全必要的。

Input Validation 输入验证

对输入信息进行检查，是防止如SQL注入、跨站脚本XSS这种内容注入类的攻击方式的有效方式。它可以防止有害的数据被无意作为恶意代码被注入到应用程序当中，或者防止无意义或者无效的过多的信息被录入系统，额外增加系统的负担而影响性能。除此之外，结合业务需求的输入验证，还可以在操作前确保数据安全有效，并符合预期的格式和约束，有利于维护系统中数据的完整性和一致性。经过检查的数据，还可以减小系统的攻击面，也有助于系统安全的提升。

输入验证操作应当基于可扩展的验证规则，这些规则可以包括各种形式，包括数据类型、文本格式、内容长度限制、取值范围、非法无效字符限制等等。当输入验证失败时，需要根据业务和安全要求，采取适当的措施，比如拒绝输入、记录和报告错误、显示错误提示信息等等。

对于前后端分离的Web应用系统，可能需要在前后端，都部署输入检查和验证体系。这里前端的验证主要考虑到用户使用体验和分层处理，可以立即处理验证信息和给用户进行反馈。真正的验证是在后端接口上执行的，它可以处理攻击者不使用前端系统，直接构造请求发起攻击的情况。

Authorization 认证

和HTTPS的必要性逻辑类似，所有的Web API的访问和调用，都应当进行认证，来确定和限定发起和请求方。后续所有的安全策略和规则、访问控制和日志审计，都会以此作为出发点和基础。所以，如果没有特别的理由，我们都应当对客户端和用户进行认证。当然，基于优化用户体验的目的，我们可以引入如OAuth2、WebAuthn这种技术，来改善和简化用户认证的操作流程。

而且基于默认安全的原则，哪怕是完全开放的服务系统，我们也需要按照正常的认证系统一样进行相关的授权和访问控制设计，只不过可以选择使用特殊或者默认的“来宾”账号操作而已，这样可以保证安全机制的一致性和可控性。

OAuth2

OAuth2是一种行业标准的授权协议，用于在不同的服务提供商之间安全地授权第三方应用程序访问来用户数据，而无需共享用户的凭证或密码。OAuth2基于密码学的原理设计和实施，可以保证服务之间的互信关系。OAuth2认证过程不需要暴露和提供用户密码，并可选第三方应用以受限的方式访问用户数据，而且应用程序本身，也不需要再额外设计认证过程，或者保存用户认证相关的敏感信息，这个机制可以大大提高对于用户隐私和数据安全的保护。

应用程序可以基于业务特定和需求，选择使用和集成OAuth2系统，可以达到简化应用系统认证相关模块的开发和部署工作的目的。OAuth2是经过实践检验的认证机制和系统，我们基本上可以认为，它的实现应该比我们自己的实现更加安全和高效；同时，使用如Google这种应用广泛的认证系统，它拥有比一般开发者或者商业系统更好更安全的用户隐私和安全控制体系，是更值得信赖的。

API Gateway

对于大型复杂的互联网应用系统，或者需要提供多样化的Web应用服务的体系，可以考虑建设和部署API网关系统。API网关的基本概念是将API的系统能力和业务能力分离，借助API网关提供的接入、导向、管理和安全等方面的能力，可以加快业务应用系统API的开发和服务，简化开发、部署和管理，并可以提供一致性的性能和安全控制能力。

我们可以将API网关看成一系列抽象能力的平台，它们可以独立于业务系统，但提供很多除业务之外的系统通用化的能力。API网关可以提供的能力非常多，开发者和系统运维人员可以根据选择应用，它们可以包括：

• 应用API接入和生命周期管理，包括创建、发布、维护和保护业务应用和API
• 多协议的支持和转换，如支持REST、WebSocket、HTTP等多种协议，并可以支持跨协议的适配和转换
• 负载均衡，通过扩展支持多个后端接口来进行快速的业务性能扩展
• 性能优化，如查询和静态数据缓存
• 访问控制，在实际访问业务系统之前，检查请求的安全凭证和权限
• 流量控制，使用限流、降级、熔断等算法，抵御DDOS攻击
• 监控日志，持续记录访问日志，监控API访问和使用状态、性能指标等等
• 集成外部服务，集成和使用外部服务如函数计算、公共数据源、消息服务等等

Rate Limiting 限流

流量限制是一种有效的Web应用安全机制。具体而言，使用限流可以从以下方面，对信息和系统安全进行提升：

• DDOS

基于其攻击的原理，DDOS攻击基本上不能避免，但可以通过一些方式，来降低其攻击的影响。限流就是一种很好的方式。限流可以避免系统由于DDOS攻击而瘫痪和崩溃。

• 暴力破解

通过限制对登录、认证或其他敏感操作的尝试次数，可以防止攻击者使用暴力破解的方式猜测密码或尝试不同的漏洞。

• API和服务滥用

限流措施可以有效保护API和服务免受滥用。通过限制请求频率，可以避免单个用户或客户端应用占用过多的系统资源，以确保所有用户都可以机会平等地访问这些资源和服务。

• 系统稳定和可用

有些系统可能天然的具有在特定的时段或者场景中的集中访问的特性。不能因为这些特性，造成系统整体稳定性和可用性的破坏。这时的限流措施，在牺牲一定用户体验和服务质量的情况下，能够最低限度的保证系统能够正常的运行和工作，并能够在高峰过去之后，恢复正常的状态和运行，也是可以被接收的。

Whitelisting 白名单

如果你的API并不是一个完全开放的系统，或者不是直接为Web前端应用提供服务的系统，而是作为一个业务应用支撑系统，为其他系统提供服务的系统(微服务)，应该考虑建立白名单体系。

白名单机制是信息系统“默认安全”这一原则的有效实践。API系统默认不为任何未经认证的客户或者系统提供服务，只有经过了验证，或者被配置在访问控制列表策略当中，才能有效使用系统服务。

和白名单相对的，还有一种“黑名单”机制。这个机制在某些应用场景中可能会更简单方便，但其实它违背了“默认安全”的基本原则，所以并不提倡优先考虑和使用。所以这里就不再深入探讨。

Leveled API Keys 分级API密钥

分层API密钥是一种按权限和访问级别分层管理API密钥的方法。通过对API的分层管理，可以有效的实现对不同用户、应用程序或服务的不同类型和策略的访问控制，从而提高API系统的安全性和灵活性。

分层API密钥通常根据访问权限和功能将密钥分为多个级别，每个级别对应不同的权限和访问范围。下面是一套常见的分级方式和思路：

• 只读密钥（Read-Only Keys） 只允许读取资源，但不允许修改、删除或执行其他写操作。这种密钥通常用于提供给需要访问资源但不需要修改它们的用户或应用程序。

• 读写密钥（Read-Write keys）

允许读取和修改资源，但可能会对特定操作进行限制。这种密钥通常用于需要对资源进行管理和修改的用户或应用程序。

• 管理密钥（Admin Keys）

具有最高权限，可以执行所有操作，包括创建、修改和删除其他 API 密钥。这种密钥通常只提供给可信的管理员或开发人员。

• 自定义权限密钥（Custom keys）

根据特定需求定制的密钥，其权限范围和访问级别可以自行设定。

当然，使用分级API密钥，也会对系统的设计和规划，密钥的存储、传输和管理，防止密钥的泄露和滥用等方面带来更多的复杂性，需要综合和全面的评估和设计。

OWASP

Open Web Application Security Project（OWASP）开放式Web应用程序安全项目是一个独立的非盈利组织，致力于提供无偿的Web应用程序安全性资源，OWASP的核心理念是通过持续提高软件质量来增强应用程序安全性。这些安全资源包括评估项目、知识框架、安全工具、规范标准、最佳实践等等。

其中 OWASP Top 10 是OWASP最著名的安全评估项目，每三年发布一次，列出了当前最重要的十种Web应用程序安全风险，旨在教育开发人员如何避免安全缺陷并解决安全漏洞，对于开发者和网络安全人员都有非常重要的指导和借鉴意义。

比如下图就形象的展示了OWASP Top 10在2017和2021年的不同版本和版本间的差异和演化。

API Versioning API版本

API 版本控制(API Versioning)是指在提供新的 API 版本时,同时保持旧版本API继续可用的做法。这样做的目的是为了避免在发布新版本时破坏现有客户端应用程序。这个措施，可以有效的提升开发、测试和应用的体验，以及业务连续性。

同时，实施已经规划好的API Version版本管理策略，可以在应用的过程中，平滑的升级和演进应用系统和服务，这里面当然包括系统安全。

WebAuthn

WebAuthn(Web Authentication)是一种新兴的Web身份认证标准，由W3C针对需要更高安全性的场景制定。它旨在取代传统的基于密码的认证方式，提供无密码、免疑难解的身份验证体验。

和传统和被人们熟知的如基于密码的认证方式相比，WebAuthn主要有以下几个关键特性:

• 无密码认证 WebAuthn使用密钥对(公钥和私钥)代替密码,消除了密码泄露和重置的风险。
• 防止网络钓鱼 认证过程建立在服务器-客户端之间通过加密信道建立的真实性连接之上,防止中间人攻击。
• 设备绑定 私钥存储在用户的安全硬件中(如USB密钥、指纹识别器等),无法被窃取。
• 抗重放攻击 认证过程中有一次性的随机数(challenge),防止重放攻击。
• 生物识别支持 WebAuthn可以进一步支持多种生物识别方式,如指纹、面部等,提升便利性
• 跨平台、跨浏览器兼容性 作为W3C标准，WebAuthn在主流浏览器和操作系统上都有较好的支持

图为WebAuthn的一个代表性的技术实现-fido2，它是一个USB接口的安全密钥设备，配合相应的认证系统和过程，可以通过简单的触摸，就完成安全的用户认证过程。WebAuthn是一个非常有发展前景的认证技术，有机会笔者会另行撰文详细探讨。

补充信息

上面就是ByteByteGo提出的API安全设计中的12个要点。除此之外，笔者结合自己在应用开发中的一些经验和思考，觉得有必要再补充几点。

Social Engineering 社会工程

在信息安全方面，社会工程是指利用人类的弱点，通过偷窃、欺骗、诱骗或威胁等手段，获得未经授权的访问或控制信息系统的行为。很多人都没有意识或者认识到，社会工程，其实是攻击者破坏信息系统安全的一个非常重要和先行的方式。我们可以通过下列常见的信息工程方法来理解这一点：

• Backgrounding 背景调查

攻击者通过调查他人身份和背景信息，窃听他人谈话，监视和偷窥他人生活和工作环境，获取相关的外围和背景的知识和信息，为进一步分析和攻击收集相关信息。例如很多人使用生日或者纪念日、昵称和宠物名称、重要事件作为密码的组成部分，攻击者通过组合分析，就可以大大减少密码猜测的范围。

• Phishing 鱼饵攻击

就是俗称的网络钓鱼。攻击者通过向目标发送带有诱惑性的电子邮件、短信或即时消息等方式，诱导用户点击恶意链接或提供个人信息。还有一种常见的钓鱼攻击的方式就是构造一个网址和内容都和真实网站很像的伪造的网站，迷惑和诱导用户输入如密码、电话号码等敏感信息。

• Pretexting 预先计划的社会工程

攻击者通过虚构身份或场景，对目标进行迷惑和欺骗，诱导目标个人或组织泄露敏感信息。

• Watering Hole Attack 水坑攻击

攻击者通过在目标用户常访问的网站上植入恶意代码，实现对其计算机的控制。

• Tailgating 尾随

攻击者利用其他人的身份认证，未经授权地进入受保护的区域。

为了有效的防范社会工程攻击，经常采取以下措施：

• 增强安全意识：提高个人和组织的安全意识，了解社会工程攻击的手段和特征
• 定期培训和测试：定期进行安全培训和测试，提高个人和组织对社会工程攻击的识别和应对能力。
• 限制信息泄露：尽量减少对外泄露个人或组织的敏感信息
• 加强身份认证：采用多因素认证或者交叉验证等方式，增强身份认证的安全性。
• 注意电子邮件、消息和网页安全：不要轻信来自不明来源的电子邮件，不要点击恶意链接或下载未知附件，留意检查网络地址和名称的正确无误，注意检查网站证书的有效性等等

Credentials Expiration 凭证期限限制

信息安全中，有一个非常重要的概念，就是所有的安全都应该有一个期限，不应当有持续性的，无法更新，不能变化的安全凭证。根据这个原则，我们设计的所有的安全凭证，无论是Token还是Session，甚至是临时性的认证信息，都应该有一个有效期限。

使用凭证期限，在很多情况下，可以简单有效的抵御重放攻击。同时动态的验证过程和信息，也使攻击者寻找认证模式和线索的工作变得更加困难和低效。这些都能够提升系统的安全性。

Multi-factor Authentication 多因子验证

MFA(Multi-Factor Authentication, 多因子认证)是一种计算机访问控制策略，它的基本概念就是客户端需要多种形式的证明才能获得系统访问权限。显然，MFA是信息系统安全纵深防御理念的一种工程实践，它比单一密码或生物识别物证更安全，而且对于攻击者而言，由于需要考虑不同领域的攻击模式，它的困难程度是指数级提升的。

多因子指的是多个认证因素，相对于被验证者而言，它们可以大致分为以下几类：

• 知识因素 Something You Know

这些包括已知或者记忆的机密信息，通常是密码、PIN码或安全问题答案等等。这里有一个小小的悖论就是你可能不知道别人也知晓了这些信息。

• 所有物因素 Something You Have

只有你拥有的事务，这可以是硬件安全密钥、智能卡、U盾或验证应用程序生成的一次性密码(如手机验证码)等用户所持有的物理设备/令牌等等，这个持有显然具有排他性，比如你丢失了安全密钥，是可以有机会去声明或者注销的。

• 固有因素 Something You Are

这主要是指生物识别特征，如指纹、虹膜、面部等与个人固有相关的特征。这个因素也有排它性，但从技术和安全角度而言，也有可能的特征冲突(相同的面部特征)，以及特征不可变更等问题。

• 位置因素 Somewhere You Are

一般指基于设备的地理位置、IP地址或与用户位置相关的其他数据。显然，这个信息不能作为主要的凭证信息，但很多系统将其作为辅助认证的信息，也能够起到一定的安全提升的作用。因为攻击者一般来自不同的地域，并且使用不同的系统或者环境，这一类信息的变化，对于认证而言是一个安全的风险。

通过结合不同类型认证因素，在不大幅度降低操作体验的情况下，可以显著的提升认证过程的安全性。

小结

本文从系统安全的一些设计原则出发，探讨了关于Web应用API安全设计和实现方面的一些相关的重要的技术和方法，可以在系统的安全和实现时进行参考和评估。