保护 REST API 的最佳实践

API 是现代数据驱动型经济的支柱。无论您是将基础架构迁移到云端，转向基于微服务的架构，还是仅仅尝试将新服务与现有的单体系统集成，您的业务都有可能依赖 API 来传输数据。随着业务的快速发展，安全性很容易被忽视。

由于您的客户和合作伙伴依赖您来保障其数据安全，因此在设计 API 时，将安全性放在首位至关重要。为此，我们提供了十条确保 API 安全的技巧。虽然这些技巧专门针对 REST API，但其中许多技巧也适用于其他类型的 API，例如 GraphQL API。

1. 始终使用传输层安全性

您的 API 应该仅公开 HTTPS 端点。这可以保护用于系统身份验证的凭据免遭传输过程中拦截，并有助于保证返回数据的完整性。

2. 使用成熟可靠的身份验证框架

避免尝试为您的 API 自行构建安全解决方案。请使用成熟的框架，例如 Auth0、OpenId Connect、Amazon Cognito 或 Firebase Authentication。这些框架拥有经验丰富的开发团队，他们已投入数千小时来排查错误、查找和修复漏洞。

3.考虑使用 API 网关服务

如果您的 API 基于云，请考虑使用云平台的 API 网关服务。此类服务可以对哪些人可以访问您的端点进行细粒度的控制。所有主流云平台都提供网关服务，额外的保护措施物有所值。

4. 将允许的 HTTP 方法列入白名单

如果您公开的端点仅使用特定方法，请将允许的方法列入白名单，并拒绝所有其他方法。例如，如果您的 API 是只读的，则可以将 GET 方法列入白名单，并拒绝任何 POST、PUT 或 DELETE 请求。

5. 始终验证用户输入

用户发送的任何输入都必须经过验证和清理，才能到达应用程序逻辑。验证过程应尽可能严格。使用强类型和正则表达式，确保收到的输入符合应用程序的预期并能够处理。考虑设置合理的请求大小限制，并拒绝任何较大的请求。所有失败的验证都应记录下来，并监控是否存在异常的请求行为。

6. 应用速率限制

对您预期从任何单一来源接收的请求数量设置合理的限制。任何超过此限制的请求都应被丢弃。这有助于防止系统遭受拒绝服务攻击。根据您的 API 结构，您可能希望通过为不同资源指定不同的限制，或根据发出请求的客户端调整限制来实现更精细的控制。

7. CORS 设置尽可能具体

CORS 代表跨域资源共享，您的设置决定了浏览器如何处理跨域请求。如果您的 API 不接受跨域请求，则应禁用 CORS。否则，您应该尽可能具体地指定允许跨域请求的域名。同样需要注意的是，CORS 严格来说是一项客户端安全功能，不应以任何方式依赖它来保障服务器端安全。

8. 利用框架的内置安全功能

无论您使用哪种开发语言，您都很有可能使用框架来构建 API。无论是 Django、Rails、Spring 还是 ASP.NET Core，几乎所有现代 API 框架都内置了一些您应该充分利用的安全功能，例如防御跨站请求伪造和点击劫持等攻击、会话安全或标头验证。话虽如此，同样重要的是，不要误以为框架的默认安全配置已经足够好。请花时间充分了解框架中可用的功能，并确保您的配置遵循最小特权原则。

9. 切勿将凭证存储在版本控制中

任何机密信息（密码、API 密钥、SSH 密钥等）都不应签入到您的版本控制系统。即使您的代码库是私有的，将凭证与源代码放在一起仍然被认为是不好的做法。您可以考虑使用环境变量将机密信息传递到应用程序中，或者使用专门用于存储机密信息的服务，例如Hashicorp 的 Vault。大多数云平台也提供用于存储和检索凭证的专属服务。

10. 返回适当的错误消息

确保所有内部错误在返回到 API 响应之前都已被捕获并处理干净。您的最终用户不应该看到任何包含系统架构详细信息的错误消息。原始错误响应通常包含堆栈跟踪，并且可能会泄露您正在使用的数据库或库等信息，攻击者可能会利用这些信息来攻击您的系统。您的错误消息应该足够具体，以便请求者了解发生了什么，但又要足够通用，以免泄露任何有关系统内部工作原理的详细信息。此外，请确保您的响应使用与给定错误语义相符的 HTTP 状态代码。

当您的客户和合作伙伴的数据处于危险之中时，安全问题绝不能被抛在脑后。它应该从一开始就被纳入规划流程。牢记这些技巧，您就能为用户设计出安全可靠的 API。有关 API 安全的更多信息，请查看OWASP 的REST 安全备忘单。