反向代理后 CrossOriginProtection 误判来源怎么办

反向代理后出现 CrossOriginProtection 误判，先看请求是否缺少 Sec-Fetch-Site，再比较浏览器的 Origin 与 Go 服务实际收到的 r.Host。标准库在缺少 Fetch Metadata 时会回退到这两个值的比较；如果代理把公网 Host 改成内网 upstream 地址，同源写请求也可能返回 403。最稳妥的修复通常是用 AddTrustedOrigin 精确登记公网 Origin，或者让受控代理保留原始 Host。

不要把客户端可伪造的 X-Forwarded-Host 无条件写回 r.Host，也不要为了解除 403 给整个站点添加绕过模式。先确认命中了哪条判断分支，再修复代理边界。

官方文档：https://pkg.go.dev/net/http#CrossOriginProtection

官方源码：https://go.dev/src/net/http/csrf.go

背景：上线代理后，旧浏览器路径突然返回 403

我第一次遇到这个现象时，浏览器访问的是 https://app.example.com，边缘代理再把请求转给 http://127.0.0.1:8080。业务 Handler 没改，认证 Cookie 也正常，但一部分 POST 请求在进入业务代码之前就变成了 403。

最容易误导人的地方是：同一页面在新浏览器里正常，某些 WebView、旧浏览器或测试客户端却失败。新浏览器通常会带 Sec-Fetch-Site: same-origin，CrossOriginProtection 在这一层已经放行，不需要比较 Host。缺少这个头时，保护器才继续读取 Origin，并把解析后的 o.Host 与 r.Host 比较。

于是公网请求的 Origin 是 https://app.example.com，它的 Host 部分是 app.example.com；后端看到的 r.Host 却是 127.0.0.1:8080。两者不相等，误判就出现了。

旧判断的问题：只盯着 X-Forwarded-Host 并不能解释结果

排查代理问题时，很多人第一反应是查看 X-Forwarded-Host 或 Forwarded。这些头对日志、重定向和外部 URL 构造很有用，但 CrossOriginProtection 的官方实现并不读取它们。源码中的回退判断直接使用 url.Parse(origin) 得到的 o.Host 与请求的 req.Host 比较。

这意味着仅仅确认“代理已经传了 X-Forwarded-Host”还不够。除非应用在可信边界内显式处理该头，否则保护器看到的仍是 r.Host。更重要的是，转发头来自请求 Header，若入口允许客户端直接提交并覆盖它，无条件信任会把 Host 注入带进安全判断。

新规则：先看 Sec-Fetch-Site，再回退到 Origin 与 Host

Go 官方文档和源码把判断顺序写得很清楚：

• GET、HEAD、OPTIONS 是安全方法，始终允许；
• Sec-Fetch-Site 为 same-origin 或 none 时直接允许；
• 该头存在但表示其他关系时，只有可信 Origin 或明确绕过模式可以豁免；
• 该头缺失时，若 Origin 的 Host 与 r.Host 相等则允许；
• 两者不等时，再检查可信 Origin 和绕过模式，否则拒绝；
• Sec-Fetch-Site 与 Origin 都缺失时，当前实现视为同源或非浏览器请求并允许。

所以，代理改写 Host 并不会让所有请求都失败。它主要影响“非安全方法 + 缺少 Sec-Fetch-Site + 带 Origin”的回退路径。把这个条件组合写进排查记录，比笼统地说“反向代理不兼容”更准确。

代码对比：先复现误判，再加入精确公网 Origin

下面的测试不需要真实代理，就能模拟后端收到内网 Host 的情况。第一组请求没有登记公网 Origin，应得到 403；第二组给保护器加入精确可信 Origin，同样的请求即可进入业务 Handler。

package proxycsrf

import (
    "net/http"
    "net/http/httptest"
    "testing"
)

func TestProxyHostMismatch(t *testing.T) {
    okHandler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(http.StatusNoContent) // 能执行到这里说明来源检查已经通过
    })

    req := httptest.NewRequest(http.MethodPost, "http://127.0.0.1:8080/account", nil)
    req.Host = "127.0.0.1:8080"                          // 模拟代理转给内网 upstream
    req.Header.Set("Origin", "https://app.example.com") // 模拟浏览器看到的公网 Origin
    // 故意不设置 Sec-Fetch-Site，触发 Origin 与 Host 的回退比较。

    blocked := httptest.NewRecorder()
    http.NewCrossOriginProtection().Handler(okHandler).ServeHTTP(blocked, req)
    if blocked.Code != http.StatusForbidden {
        t.Fatalf("未配置可信来源时状态码=%d，期望 403", blocked.Code)
    }

    protection := http.NewCrossOriginProtection()
    if err := protection.AddTrustedOrigin("https://app.example.com"); err != nil {
        t.Fatalf("登记可信 Origin 失败: %v", err) // 配置错误应在启动或测试阶段暴露
    }

    allowed := httptest.NewRecorder()
    protection.Handler(okHandler).ServeHTTP(allowed, req)
    if allowed.Code != http.StatusNoContent {
        t.Fatalf("登记可信来源后状态码=%d，期望 204", allowed.Code)
    }
}

AddTrustedOrigin 使用完整 Origin 精确匹配，格式为 scheme://host[:port]。不要写路径，也不要用主机后缀或通配符替代真实来源。生产、预发布和本地开发的 Origin 应分别配置，避免把测试入口带进生产信任清单。

修复方案对比：我更倾向先显式登记公网来源

对我来说，显式可信 Origin 的优点是判断依据仍然来自浏览器 Origin，规则也能在代码审查和部署配置中直接看到。代理保留原始 Host 同样可行，但它会影响日志、路由和其他中间件，改动面通常更大。

如果一定要从转发头恢复 Host，应把“请求来自受信代理”作为前置条件，例如入口网络只允许负载均衡器访问，应用还校验代理地址或使用平台提供的可信代理机制。不要写一个对所有请求都执行 r.Host = r.Header.Get("X-Forwarded-Host") 的中间件。

兼容注意：有些“修复成功”其实只是绕开了那条分支

测试时如果手动加上 Sec-Fetch-Site: same-origin，请求会在更前面直接通过，这并不能证明代理 Host 已经修好。反过来，只用 curl 且不发送 Origin 与 Sec-Fetch-Site，请求也会被允许，因为官方实现把它视为非浏览器调用。排查必须保留真实失败请求的关键头部组合。

拒绝日志建议记录方法、路由模板、Origin、Sec-Fetch-Site 和后端看到的 Host，不要记录 Cookie、Authorization 或请求体。若日志显示现代浏览器发送了 same-origin 仍被拒绝，应继续检查是否有其他中间件、重复包装或自定义拒绝逻辑，而不是继续调整代理 Host。

另外，CrossOriginProtection 不是身份认证。没有浏览器来源头的服务请求可能通过来源检查，仍必须依靠令牌、mTLS、签名或其他认证机制。CORS 也不能替代它：CORS 主要决定浏览器脚本能否读取跨源响应，而这里处理的是非安全跨源请求能否进入业务 Handler。

采用建议：把代理拓扑写进回归测试

我会为每种真实入口保留一张很小的测试表：公网 Origin、后端 r.Host、是否携带 Sec-Fetch-Site、预期状态码。至少覆盖现代同源浏览器、缺少 Fetch Metadata 的同源请求、未登记的攻击者 Origin、可信跨子域前端以及无浏览器头的机器调用。

修复上线后，再观察 403 指标是否只剩真正的跨源写请求。若同一个服务支持多个自定义域名，逐个登记 Origin 可能变得难以维护，这时应重新设计域名准入和认证模型，而不是把任意 Host 或转发头都加入信任计算。

相关问题

为什么新 Chrome 正常，WebView 却失败？ 常见原因是新浏览器带 Sec-Fetch-Site 并提前通过，旧 WebView 缺少该头而进入 Origin/Host 回退比较。

只设置 X-Forwarded-Host 有用吗？ CrossOriginProtection 本身不读取它。必须由受信代理保留 Host，或由经过严格信任校验的应用层处理。

能否直接把内网 upstream 加入可信 Origin？ 通常不能解决浏览器请求，因为浏览器发送的是公网 Origin。应登记浏览器实际发送的完整公网 Origin。

默认拒绝状态是什么？ 通过 Handler 包装时默认返回 403，也可以用 SetDenyHandler 统一响应和审计日志。