设计API时候应该注意的坑 - 26点的博客26点的博客

为了解决 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 的使用者，让使用者在需要时重新设置凭证，从而保护他们的安全。

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 的依赖关系——它们维护得好吗？你使用的是最新版本吗？有什么历史问题？也许最重要的事情是想一下：真的需要一个库来实现你正在做的功能吗?