后端面试题：为什么带凭据的 HTTP API 不应依赖重定向到 HTTPS？
题目与适用场景
你的认证 API 同时监听 HTTP 和 HTTPS，HTTP 请求会 301 到 HTTPS。请说明这个设计的风险、服务端和客户端应如何改造，以及如何兼容旧客户端。题目基于 IETF HTTPAPI 工作组 2026 年 5 月更新的 Internet-Draft；该文档仍是 work in progress，不能当作最终 RFC。
面试官考察点
- 能否指出重定向发生前凭据已经经过明文网络。
- 能否组合 HSTS、HTTPS DNS 记录、端口阻断与安全 Cookie 等控制。
- 能否处理共享主机、旧客户端、代理和凭据撤销等现实约束。
- 能否用可验证指标证明风险下降，而不是只说“全站 HTTPS”。
回答前需要澄清的问题
- HTTP 与 HTTPS 是否使用同一主机名和同一监听入口？
- 凭据是 Bearer token、Cookie、API key，还是请求签名？
- 是否有无法立即升级的旧客户端、企业代理或内网调用？
- HTTP 入口是否还承载无需认证的资源？
- 是否已有 HSTS、HTTPS DNS 记录、密钥轮换和审计日志？
30 秒回答框架
重定向不能挽回已经发出的明文凭据；被动监听者可能复制 Bearer token 或 Cookie。认证 API 应优先让 HTTP 入口在建立连接前失败，使用 HTTPS DNS 记录和 HSTS 降低首次与后续误配；Cookie 设置 Secure，客户端默认拒绝不安全连接。无法立即阻断时，对带凭据的明文请求统一返回 403，并按策略撤销可能泄露的凭据，避免根据凭据真假产生不同响应。迁移期间保留明确指标、灰度和回滚窗口。
分步骤深入解答
1. 说明重定向的泄露时点
客户端先发送 HTTP 请求，可能已经包含 Authorization、Cookie 或 API key；服务器之后返回 301，并不能擦除网络中已经暴露的内容。攻击者可重放 Bearer token 或 Cookie。即使最终 HTTPS 请求成功，应用也可能让错误配置长期不被发现。
2. 设计服务端入口
对认证端点，优先关闭公网明文监听，或让 80 端口只服务明确的网络来源。不要把 301 当成安全控制。若共享主机必须保留 HTTP，网关要识别带凭据的请求并统一返回 403，不透露凭据是否有效。
HTTP/1.1 403 Forbidden
Cache-Control: no-store
Content-Length: 0返回行为不能因凭据有效或无效而不同，否则攻击者可借此测试窃取的凭据。
3. 让客户端减少首次误配
HTTPS DNS 记录可在连接阶段提示客户端使用安全连接；HSTS 让成功建立 HTTPS 后的后续连接自动升级。两者都不是万能的：HSTS 依赖此前成功连接和客户端实现，DNS 记录也可能被阻断。因此应在 SDK、CLI 和配置校验中默认拒绝 http，并在日志中提示可操作的修复路径。
4. 限制凭据的使用范围
Cookie 应带 Secure 属性；令牌应限制在安全上下文，必要时采用绑定到请求或连接的签名机制。不同凭据不能套用同一个撤销策略：直接可重放的 API key、Bearer token 和 Cookie 通常要立即撤销，只有不可伪造请求的派生签名才可能保留。
5. 处理已经泄露的凭据
收到带凭据的明文请求后，应将凭据视为潜在泄露。服务端可以先统一 403，再在安全连接上的下一次使用返回“凭据已撤销”的可诊断错误。撤销动作要写入审计日志，通知持有者轮换，并避免把敏感值写入日志、缓存或错误响应。
6. 兼容与迁移
先在 SDK 和测试环境拒绝 HTTP，再对新租户默认关闭明文入口，最后分批迁移旧租户。为必须使用旧代理的客户提供短期专用过渡入口，但不得接收认证凭据；设置截止日期、监控 403 比例和轮换完成率。若共享主机的无认证资源仍需 HTTP，应把认证 API 拆到独立主机名或网关策略。
7. 验证安全性
检查网络抓包中不存在 Authorization、Cookie 或 API key；验证 HTTP 入口的连接失败与 403 行为，测试 HSTS 缓存、首次访问、代理、重试和回滚。指标包括明文请求数、带凭据的明文请求数、自动撤销数量、403 误报率、旧客户端占比和迁移完成率。
高质量示范回答
我不会把 301 重定向当作认证 API 的安全方案，因为凭据在重定向前已经走过明文网络。被动监听者可以复制 Bearer token 或 Cookie，成功的 HTTPS 重试反而会掩盖客户端配置错误。
服务端先关闭认证端点的公网 HTTP 监听；如果共享主机暂时不能关闭，网关对所有带凭据的 HTTP 请求统一返回 403，不根据凭据真假改变响应，并把凭据标为潜在泄露。对可重放的 token、API key 和 Cookie 执行撤销和轮换。客户端 SDK、CLI 和配置校验默认拒绝 http，服务端同时使用 HTTPS DNS 记录和 HSTS 降低首次及后续误配，Cookie 设置 Secure。
迁移按新租户、测试环境、旧租户分批进行，给企业代理一个不接收凭据的短期过渡窗口。验收看抓包、明文请求数、带凭据明文请求数、撤销与轮换完成率、403 误报率和旧客户端占比。这样既解决泄露路径，也给出可回滚的迁移计划；IETF 文档仍是草案，具体部署承诺应保持可调整。
常见错误
- 认为 HTTPS 重定向可以保护已经发送的 Authorization 或 Cookie。
- 只配置 HSTS，却忽略首次连接、旧客户端和非浏览器 SDK。
- 对有效和无效凭据返回不同的明文响应，泄露可测试信号。
- 把所有凭据都当作同一种，忽略签名派生值与可重放 token 的差异。
- 直接删除 HTTP 入口，却没有迁移、监控、撤销和回滚计划。
追问及应对
如果 HTTP 入口还服务公开资源怎么办？
把认证 API 迁到独立主机名，或在网关按路径和凭据头做隔离。公开资源可有自己的重定向策略，认证端点必须拒绝带凭据的明文请求。
HSTS 能解决首次访问吗？
不能完全解决。HSTS 需要客户端先成功建立 HTTPS 并持久化策略；因此 SDK、配置校验、HTTPS DNS 记录和部署检查仍需共同覆盖首次连接。
什么时候撤销凭据？
只要凭据在明文请求中出现，就按潜在泄露处理。可重放 token、API key 和 Cookie 应撤销并轮换；仅暴露不可伪造的派生签名时，依据威胁模型决定是否撤销。
如何避免升级造成大面积中断？
先在测试和新租户启用拒绝，观测旧客户端与 403 误报，再分批迁移。保留不接收凭据的短期过渡入口和明确截止日期，完成后删除过渡路径。