Go HTTP 服务安全响应头怎么配：HSTS、nosniff 与代理信任边界

浏览器是否强制使用 HTTPS、是否把脚本当成别的类型、请求跳转时带不带来源信息，很多时候不是前端代码决定的，而是 HTTP 响应头决定的。Go 服务如果只把这些头交给某一层代理添加，直连端口、灰度入口和本地调试环境就可能出现不同结果。把基础安全头放在应用响应链路里，并明确代理信任边界，排查起来更稳。

先把三类响应头分清楚

安全响应头不是越多越好，先按浏览器行为分组更容易落地：

• 协议升级：HSTS 告诉浏览器在一段时间内只用 HTTPS 访问域名。
• 内容类型：X-Content-Type-Options: nosniff 禁止浏览器擅自猜测响应类型。
• 来源信息：Referrer-Policy 控制跳转或加载资源时发送多少来源地址。

这三项解决的是不同问题。HSTS 不是 TLS 配置，nosniff 也不能替代正确的 Content-Type；如果接口返回 JSON，服务仍应明确写出 application/json。

在 Go 中集中设置基础响应头

推荐把策略集中在一个包装器中，避免每个处理函数各写一遍，也方便后续统一测试：

func securityHeaders(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("X-Content-Type-Options", "nosniff")
        w.Header().Set("Referrer-Policy", "strict-origin-when-cross-origin")

        // 只有全站 HTTPS 且确认域名策略后才打开 HSTS。
        if r.TLS != nil {
            w.Header().Set("Strict-Transport-Security", "max-age=31536000")
        }
        next.ServeHTTP(w, r)
    })
}

这里用 r.TLS != nil 只适合 Go 服务直接终止 TLS 的场景。如果 TLS 在反向代理处终止，应用收到的请求通常没有 TLS 状态，不能直接相信客户端随手带来的 X-Forwarded-Proto。否则攻击者可以伪造协议标记，或者让 HTTP 入口错误地发出 HSTS。

生产配置应通过已知代理网段、可信连接或框架提供的代理解析规则确认来源，再决定是否把“外部协议为 HTTPS”当作事实。代理信任表发生变化时，安全头测试也要跟着更新。

HSTS 的开启边界不能省略

HSTS 会被浏览器缓存。max-age=31536000 意味着浏览器在一年内倾向于把该域名的 HTTP 地址升级为 HTTPS。域名下若仍有必须使用 HTTP 的旧服务，或者证书、重定向链还没有验证完整，过早打开会把问题变成用户侧的持续访问失败。

比较稳妥的上线顺序是：

1. 确认主域名和需要覆盖的子域名都能稳定走 HTTPS。
2. 先用较短的 max-age 在小流量入口观察重定向、静态资源和回调逻辑。
3. 再逐步延长时间；只有明确管理所有子域名时，才考虑 includeSubDomains。

不要为了“看起来更安全”直接拼上 preload。它涉及浏览器预加载名单和域名全量 HTTPS 条件，应该单独评估后再做决定。

用 httptest 检查头是否真的发出

中间件测试不需要启动完整服务，关键是让请求分别模拟直接 TLS 和普通 HTTP，并明确检查每个头的预期值：

func TestSecurityHeaders(t *testing.T) {
    next := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "application/json")
        w.WriteHeader(http.StatusNoContent)
    })
    h := securityHeaders(next)

    t.Run("tls", func(t *testing.T) {
        req := httptest.NewRequest(http.MethodGet, "https://example.test/data", nil)
        req.TLS = &tls.ConnectionState{}
        rec := httptest.NewRecorder()
        h.ServeHTTP(rec, req)
        if got := rec.Header().Get("Strict-Transport-Security"); got == "" {
            t.Fatal("missing HSTS")
        }
        if got := rec.Header().Get("X-Content-Type-Options"); got != "nosniff" {
            t.Fatalf("nosniff = %q", got)
        }
    })
}

还应补一个普通 HTTP 用例，确保当前实现不会误发 HSTS；如果服务前面有代理，再增加集成测试验证“可信代理传来的 HTTPS 状态”才能开启策略。响应头测试最好放在路由注册附近，后续新增入口就不容易绕开这层逻辑。

上线前的四个复查点

不要把客户端头当成事实

X-Forwarded-Proto、X-Forwarded-Host 等字段只有来自可信代理时才有配置意义。应用若直接暴露公网，应先清理或拒绝外部伪造的这些值。

响应类型要和内容一致

nosniff 生效后，错误的媒体类型更容易暴露。JSON、CSS、JavaScript 和下载文件都要有准确的 Content-Type。

确认重定向和回调没有 HTTP 依赖

启用 HSTS 前检查登录回调、支付回调、图片域名和旧版客户端。浏览器强制升级后，隐藏的 HTTP 依赖会集中暴露出来。

用外部检查和应用测试各看一次

应用测试证明代码设置了头，线上检查才能证明代理没有覆盖、删除或重复拼接。两者缺一不可。

常见问题

HSTS 能替代 HTTPS 证书配置吗？

不能。HSTS 只告诉浏览器如何访问，证书、协议版本、加密套件和重定向逻辑仍需单独配置。

为什么应用里设置了 HSTS，线上却没有？

常见原因是请求在代理终止 TLS，应用看到的 r.TLS 为空，或者代理覆盖了响应头。先核对可信代理规则和最终返回的响应内容。

Referrer-Policy 应该用哪个值？

对大多数站点，strict-origin-when-cross-origin 是一个兼顾隐私和调试的起点；如果业务不需要来源信息，可以再按需收紧。

把安全头变成可回归的默认值

Go 服务的安全响应头适合做成统一中间件：先默认开启低风险的 nosniff 和来源策略，再根据真实 HTTPS 边界决定 HSTS。不要相信未经验证的代理字段，也不要把浏览器缓存策略当作 TLS 修复。最后用 httptest 检查代码、用线上响应检查链路，安全头才算真正落地。