12 个设计 API 的安全建议，不要等出事儿了“捶胸顿足”

原文地址：API Security Best Practices

原文作者：Mark Michon

译者 & 校正：HelloGitHub-小鱼干 & HelloGitHub-鸭鸭

虽然本质上 API 就是拿来用的，但即便某个 API 的使用者全是内部人员，它还是可能会出现安全问题。为了解决 API 安全问题，在本文我们收集了一系列 API 的最佳实践，希望你记住这些 Tips 日后在保护 API/Web 服务安全和免受入侵时，会帮助到你。

1、使用 HTTPS

现在的 Web 已经不是之前那个年代，标准的 HTTP 满足不了 Web 安全需求。而各大浏览器供应商开始标记不使用安全层的 URL，你的 API 也可以考虑开始动手做这件事——用 HTTPS。HTTPS 采用传输层安全性协议（TLS）对传输进行加密。这意味着 HTTPS 对客户端和服务器之间的通信进行加密。对 API 而言，HTTPS 意味着从 API 发送的内容是受第三方保护的，但更重要的是这意味着访问凭证是安全的。

2、认证

说到访问凭证，避免意外使用 API 的最直接的方法便是确保正确的身份验证。身份验证决定了你是否可访问 API 及如何访问某个 API，即便是对外开放的免费 API 理论上也应当考虑采用身份验证策略以保证安全性。有了身份认证，你可以限制或删除滥用 API 的使用者，让使用者在需要时重新设置凭证，从而保护他们的安全。了解更多有关 API 身份验证的知识可以阅读《三种最常见的认证方法》。

3、授权

起到和身份验证类似作用的是授权。身份验证和授权的区别在于，身份验证关注的是 API 的使用者是谁，而授权关注的是他们能够访问的内容。举个例子，免费计划用户可能被授权只能访问你所有 API 的某个子集。当你想集成诸如社交登录此类 API 时，用户授权可让应用从社交平台读取他们的配置文件数据。

4、安全 endpoints 和资源（对象级授权）

一般来说，我们会通过授权来保护 endpoint/endpoints，但更长远来说，我们需要确保单个资源的安全。单个资源的安全可以防止错误配置的 endpoint 级授权访问数据。此外，它还意味着 endpoint 本身不受用户类型的限制，而是由资源控制谁能查看它，谁不能查看它。（精确到 URL 的权限）

5、限速

一说到安全，我们常会想到不适当的访问。当然，如何处理不适当的访问对管理资源也很有用。限速是一种限制 API 使用的技术。它不仅在经济上保护资源，但也保证了服务器不会因某次大量的请求而超载。大多数限速的方法都基于时间的——一般会设置一个账单周期来处理 API 总体使用情况，也会用“突发”方法来限制大量涌入的请求。如果你看到 429 HTTP 状态代码，说明你正在被限速。

6、验证和净化输入

要攻击 Web 程序最古老的方式之一是输入，即：我们访问数据的方式可能已经改变，但是验证任意用户输入的需要还没有改变。客户端验证有助于防止错误和改善用户体验，但是 API 还需要在对输入执行操作前验证和净化（sanitize）输入——净化策略为删除请求中的恶意或无效代码。验证确保数据满足资源期望的必要条件，例如：类型、形式，甚至是密码结构等因素。

7、按需公开

采用快捷方式将数据模型直接映射到接口是很诱人，但这不仅会产生冗长的响应、增加带宽使用，而且还会暴露用户不需要访问的数据。举个例子：一个 /user 接口要返回用户信息。它可能只要用户的一些基本信息，而不需要用户的密码/权限。

8、错误消息的配置

除了对 API 的输入数据进行净化（sanitize）外，还需要对从中产生的信息进行净化。错误消息对用户了解问题的发生至关重要，但要确保不泄漏任何敏感数据。向终端用户提供 API 内部代码结构的详细信息会为攻击者提供便利，所以一定要确保错误信息的配置不仅能提供足够的信息来帮助用户调试，并提供足够的信息让他们报告问题，但又不足以暴露应用程序的内部工作和敏感数据。

9、不要暴露敏感信息

API 开放要建立在保护敏感数据之上，要确保不要在 JSON Web Token 和缓存中公开细节。JWT（JSON Web Token） body 给人一种很安全的错觉，其实它很容易破译。因此，应该避免 JTW 和缓存中，包含可用于访问应用程序的用户信息。同样的建议也适用于 URL，要确保查询字符串不会暴露敏感数据的细节。

10、评估依赖

开发过程中我们并不是完全自己编写代码，大多数情况下，代码很大一部分会包含库、中间件和各种来自外部源的依赖关系。虽然一般情况下我们可以认为流行的软件包是经过实战测试的，但即便如此，并不意味着这些依赖完全避免漏洞。因此，要确保你评估过 API 的依赖关系——它们维护得好吗？你使用的是最新版本吗？有什么历史问题？也许最重要的事情是想一下：真的需要一个库来实现你正在做的功能吗?

11、允许用户跟踪和重置身份验证密钥

提高 API 安全性的另一种方法是允许用户重置他们的凭证并监视使用情况。一个常见的错误是不允许使用者重置他们的 API 密钥。如果 API 使用者意外地公开了他们的密钥，或者恶意获取密钥，那么这个问题现在会直接影响你的 API。相反，为了保证安全，你可以为他们创建一种管理访问的方法。

12、标准化服务中的认证

我们看到像谷歌、微软和亚马逊这样的 API 巨头都对它们的 API 授权和认证过程进行了标准化。我们不妨考虑一种集中的方法，比如使用 API 网关或专用的入口点来处理身份验证请求。

遵循 OWASP 标准指南

除了这些最佳实践之外，可以考虑采用开放式 Web 应用程序安全项目（Open Web Application Security Project，缩写 OWASP）的建议。他们提供了特定平台的指导，以及即将推出的特定 API 的指导——API 安全 Top 10。除了在代码层面保护 API 之外，还需要确保正确配置服务器和基础设施，以避免未经授权的访问。

译者有话说：本文的最后一段作者安利了自家产品，因此译者不做翻译，本文若有任何更佳的翻译，欢迎留言交流^^

加入 HelloGitHub 的「译文亦舞」系列 要求：

平时阅读 GitHub、开源、编程、程序员的英文资讯和文章
每月至少翻译或校正 1 篇文章
翻译不失原味且通顺
了解 Markdown、排版规则

欢迎优秀的你加入，让你的才华舞动起来！把优秀的文章分享给更多的人。我的微信：xueweihan （备注：翻译）