Go 1.25 http.CrossOriginProtection 怎么拦跨源不安全请求：请求头判断与路由接入

升级到 Go 1.25 后，如果一个带 Cookie 的写接口需要挡住跨站表单或脚本请求，可以把 http.CrossOriginProtection 放在现有路由前面。它依据浏览器的 Sec-Fetch-Site 和 Origin 判断跨源关系，安全方法继续通过，疑似跨源的非安全请求默认返回 403 Forbidden。

最小接入方式是用 http.NewCrossOriginProtection().Handler(mux) 包住业务路由；先确认写操作没有放在 GET 上，再按实际前端来源补充可信 Origin。

跨源写请求为什么会在入口被挡住

现场通常很简单：页面正常打开，GET 查询也正常，但从另一个站点提交 POST 时得到 403。先别急着在业务函数里加一堆来源判断。浏览器会带上 Sec-Fetch-Site，也可能带上 Origin；保护器在进入应用路由前读取这些信号，并把安全方法和非安全方法分开处理。

这项能力不是 Cookie 校验，也不是 CSRF token。它的价值是给一组已经存在的 net/http 路由增加统一的跨源请求门槛。真正改变数据的接口仍然应该使用 POST、PUT、PATCH 或 DELETE，并在业务层继续验证身份、权限和输入。

先用 Check 看清请求头判定链

如果需要在中间件接入前观察拒绝原因，可以直接调用 Check。下面的示例只打印判定结果，不执行任何写操作；测试时用 httptest.NewRequest 逐个补齐请求头。

package main

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

func main() {
    protection := http.NewCrossOriginProtection()
    req := httptest.NewRequest(http.MethodPost, "http://api.example.test/orders", nil)
    req.Header.Set("Sec-Fetch-Site", "cross-site")
    req.Header.Set("Origin", "https://shop.example.test")

    if err := protection.Check(req); err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println("request allowed")
}

这段测试里，Sec-Fetch-Site 和 Origin 是输入，Check 是判定点。两个信号的具体组合交给标准库处理，不要在业务代码里复制一份不完整的规则。官方文档还明确说明：GET、HEAD、OPTIONS 总是允许，因此不能把“请求通过保护器”理解成“请求安全”。

把 Handler 放到 ServeMux 外层

生产接入点应当是统一的 HTTP 入口。业务路由继续负责返回成功结果，保护器负责在调用链前面拦截请求：

mux := http.NewServeMux()
mux.HandleFunc("/orders", func(w http.ResponseWriter, r *http.Request) {
    w.WriteHeader(http.StatusOK)
    _, _ = w.Write([]byte("request allowed"))
})

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

// http.ListenAndServe(server.Addr, server.Handler)

当请求被 Handler 判定为不允许时，业务函数不会被调用，默认响应是 403 Forbidden。允许的请求才会继续抵达 ServeMux，最后得到 request allowed。这条边界很重要：拒绝响应应在入口统一观察，订单写入、审计日志和幂等键处理都不应在拒绝之后才补救。

可信来源和旁路规则要谨慎添加

同一套 API 同时服务多个前端域名时，可以调用 AddTrustedOrigin 放行精确匹配的 Origin。它接受形如 scheme://host[:port] 的值，生产环境不要把整段来源匹配写成宽泛通配。

AddInsecureBypassPattern 的语义更强：匹配该路径的请求全部允许，而且规则使用 ServeMux 的模式和优先级。它适合经过明确评审的兼容入口，不适合用来给所有写接口开后门。若规则冲突或模式非法，方法会 panic；配置应在服务启动阶段完成。

怎样验证拒绝、放行和回滚

上线前至少做三组请求：同源写请求、跨源写请求和安全方法请求。观察业务处理函数是否被调用、状态码是否符合预期，以及审计日志中是否能区分被入口拒绝的请求。

• 拒绝检查：POST 携带 Sec-Fetch-Site: cross-site，预期得到 403 Forbidden，业务日志不应出现订单写入。
• 放行检查：使用已配置的精确 Origin，再发同一个 POST，预期进入业务函数并返回 request allowed 或真实业务结果。
• 安全方法检查：GET、HEAD、OPTIONS 即使跨源也会通过保护器，必须确认它们没有改变状态。

如果兼容性问题集中在某个前端来源，优先回滚这次中间件接入，再单独核对 Origin 和部署域名；不要为了恢复流量直接增加全路径旁路。

相关问题

没有 Sec-Fetch-Site 和 Origin 的请求会怎样？

标准库目前把它们当作同源或非浏览器请求而允许。它不能替代登录认证、权限检查或请求签名。

CrossOriginProtection 能代替 CSRF token 吗？

它提供的是跨源请求保护，不是业务级 token 校验。高风险写操作仍可叠加 token、SameSite Cookie 和权限校验。

为什么 GET 跨源请求没有被拒绝？

GET、HEAD、OPTIONS 被定义为安全方法。若 GET 会修改订单、余额或配置，应改成语义正确的非安全方法。

收尾检查

接入 http.CrossOriginProtection 的关键不是把所有请求挡住，而是让跨源写请求在统一入口先经过可解释的判定。保留真实来源、方法语义和业务权限三层检查，出现误拦截时也能只回滚中间件配置，不动订单处理代码。