Your API Shouldn't Redirect HTTP to HTTPS

本文作者提出，API 不应将 HTTP 请求重定向到 HTTPS，而应通过清晰的错误响应或禁用 HTTP 接口来处理未加密请求。以下是内容的详细说明：

背景

当用户将其浏览器指向 HTTP URL 时，服务通常会将请求重定向到相应的 HTTPS 页面。然而，这种未加密的通信流程存在缺陷，如网络中间人（MITM）攻击可能窃取密码和其他机密信息。尽管重定向帮助早期网络向加密网络过渡，但对于 API 来讲，其适用性值得重新审视。

重定向的问题

• 静态 HTTP 重定向：用于用户界面的浏览器会话中 HTTP 到 HTTPS 的重定向是常见做法。但这种做法同样被广泛应用于 API 上，使得 API 客户端可能不会记录看到的 HSTS 头信息。
• 隐藏错误：在开发过程中，一个简单的拼写错误，例如将 "https://" 错写为 "http://"，API 请求会静默地被重定向到 HTTPS。这样会导致 API 密钥在传输过程中以明文发送，然后再次发送到加密终端，增加数据泄露的风险。

失败的快速原则（Fail-fast Principle）

作者主张 API 为未加密请求快速失败，而不是执行重定向。这可以通过禁用 API 服务器的 HTTP 接口，或返回描述性错误消息与 403 状态码实现。这样，开发者能够迅速发现并纠正错误，防止数据泄露。

常见 API 实践调查

作者调查了多个知名 API 的行为，并总结了其对 HTTP 请求的响应方式：

• 返回错误：
  • Stripe API、Google Cloud API、Shopify API 等返回 403 错误和描述性信息。
  • NPM Registry API 返回 426 错误（要求升级）。
• 禁用 HTTP 接口：
  • Fastmail JMAP API 禁用了整个 HTTP 接口。
• 重定向到 HTTPS：
  • ActiveCampaign、Atlassian Jira REST API、Anthropic API 等仍然执行 HTTP 到 HTTPS 的重定向。

最佳实践需改进

尽管针对面向用户的应用程序，HTTP 重定向到 HTTPS 经常被列为最佳实践，但对于 API，这种重定向的方式存在明显的弊端。规范中应明确指出，API 不应进行这种重定向，而应拒绝未加密的请求。

结论

对于 API，与其重定向 HTTP 请求到 HTTPS，不如采用快速失败的策略，以便开发者能在早期阶段及时发现不安全的拼写错误。这样可有效防止 API 请求中的敏感数据在网络中以明文方式传输。虽然许多知名 API 仍在使用 HTTP 到 HTTPS 的重定向，但作者呼吁调整最佳实践，以明确推荐 API 拒绝未加密请求。

附加内容：其他处理方式

作者还提到遇到了一些既不重定向也不做失败处理的 API 提供商，并已通过其安全渠道联系了这些提供商，期待获得反馈和改进。这些踢皮球的处理方式也说明了在安全实践上的不同认识。