Go http.CrossOriginProtection 怎么防跨源请求：同源策略、预检与上线验收

线上接口明明有登录校验，安全评审却仍然指出“浏览器跨源 POST 没有统一拦截”。如果请求带着用户 Cookie 从别的网站发起，单靠业务层的身份判断并不能说明请求意图可信。Go 1.25 的 net/http.CrossOriginProtection 提供了一层标准库级的请求检查：安全方法直接放行，对被识别为跨源的非安全浏览器请求返回 403。

它适合放在 HTTP Handler 的入口，先挡住明显的跨源写请求；但它不是鉴权、CORS 或业务授权的替代品，接入后仍要用真实请求头和业务接口做验收。

先看它拦截的到底是哪类请求

CrossOriginProtection 关注的是浏览器上下文中的跨源请求，而不是所有带不同 Host 的网络流量。官方实现优先检查 Sec-Fetch-Site，也会在缺少该头时比较 Origin 与 Host。因此，服务端测试里随手拼一个没有这些头的请求，不能直接证明防护没有生效。

安全方法 GET、HEAD 和 OPTIONS 始终允许。这里的“安全”只表示防护组件不会因为跨源属性拒绝它们，不代表业务可以在 GET 中执行删除、改密或状态变更。

把防护层接到 Handler 入口

最小接入方式是把业务路由交给 Handler 包装。入口统一后，后续新增的写接口也会经过同一层检查，避免每个处理函数各写一套判断。

mux := http.NewServeMux()
mux.HandleFunc("/profile", updateProfile)

protection := http.NewCrossOriginProtection()
server := &http.Server{
    Addr:    ":8080",
    Handler: protection.Handler(mux),
}

log.Fatal(server.ListenAndServe())

默认拒绝处理器返回 403。若前端需要稳定的 JSON 错误格式，可以调用 SetDenyHandler，但不要在拒绝分支里泄露 Cookie、Origin 或内部路由细节。

可信来源要精确到 Origin

跨源管理后台确实可能需要调用写接口，这时用 AddTrustedOrigin 明确加入完整的 scheme、主机和可选端口，例如 https://admin.example.test。它匹配的是 Origin 头的精确值，不是任意后缀域名。

protection := http.NewCrossOriginProtection()
if err := protection.AddTrustedOrigin("https://admin.example.test"); err != nil {
    log.Fatal(err)
}

配置错误要在启动阶段暴露，而不是等到第一次请求才发现。Origin 白名单也应与部署环境配置绑定，测试域名、预发布域名和生产域名分别维护，避免把临时站点带进长期白名单。

最容易误用的是路径绕过

AddInsecureBypassPattern 的名字已经说明风险：匹配到的请求会被直接允许。它适合非常窄的兼容场景，例如一个已经由独立签名机制保护、且不依赖浏览器 Cookie 的入口；不应该为了让某个前端页面“先跑起来”就把整个 /api/ 放进去。

路径模式遵循 ServeMux 的语法和优先级，而且只匹配请求本身。会被 ServeMux 规范化或重定向到另一条模式的请求，并不会自动获得同样的绕过权限。上线前应把尾斜杠、路径清理和方法组合都列进测试。

用四组请求完成上线验收

验收不要只看“服务能启动”。至少准备一组安全方法、一组同源写请求、一组跨源写请求和一组可信 Origin 写请求，记录状态码、拒绝处理器输出以及业务处理器是否实际被调用。

func TestCrossOriginBoundary(t *testing.T) {
    p := http.NewCrossOriginProtection()
    handler := p.Handler(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.WriteHeader(http.StatusNoContent)
    }))

    req := httptest.NewRequest(http.MethodPost, "http://api.example.test/profile", nil)
    req.Header.Set("Sec-Fetch-Site", "cross-site")
    rr := httptest.NewRecorder()
    handler.ServeHTTP(rr, req)

    if rr.Code != http.StatusForbidden {
        t.Fatalf("status = %d, want 403", rr.Code)
    }
}

再补一条带同源 Fetch Metadata 的 POST、一条 GET 和一条已配置可信 Origin 的 POST。测试里不要只断言 403，还要断言被保护的业务处理器没有副作用；线上则把拒绝计数和路由维度日志接入现有监控。

常见问题：几个边界别混在一起

它能代替 CSRF Token 吗

不能把它当成所有 CSRF 防护的唯一答案。它利用现代浏览器 Fetch Metadata 和 Origin 信息做入口拦截；非浏览器客户端、旧环境和特殊代理链路仍需结合鉴权、SameSite Cookie、请求签名或业务幂等策略判断。

为什么没有请求头的测试会通过

官方语义把同时缺少 Sec-Fetch-Site 和 Origin 的请求按同源或非浏览器请求处理。这是兼容性取舍，不是测试捷径。要测跨源拒绝，必须显式构造能够表达跨源上下文的请求。

CORS 放开后还需要它吗

需要分别看目的。CORS 决定浏览器是否允许脚本读取响应，CrossOriginProtection 关注跨源请求是否应被服务端拒绝；一个配置允许跨域读取，不能自动推出写请求可信。

结语

把 CrossOriginProtection 放在路由入口，先用默认规则覆盖跨源非安全请求，再用精确 Origin 处理确有业务需要的跨源客户端。最后用请求头、状态码和业务副作用三件事一起验收，才能知道防护是真的生效，而不是只在代码里“看起来接上了”。