CrossOriginProtection 为什么拒绝没有 Origin 的请求

我第一次把 http.NewCrossOriginProtection() 接到写接口前面时，最容易误判的一条日志就是“没有 Origin，所以被拒绝”。但按 Go 当前 net/http 文档，同时没有 Sec-Fetch-Site 和 Origin 的请求会被当作同源请求或非浏览器请求，默认放行。真正触发拒绝的，通常是请求带有跨源证据，或者 403 来自外层网关、自定义中间件。

官方地址：https://pkg.go.dev/net/http#CrossOriginProtection

先把“没有 Origin”与“跨源”分开

CrossOriginProtection 不是“必须携带 Origin 才能访问”的请求头校验器。它先看浏览器可能提供的 Sec-Fetch-Site，再结合 Origin 与服务端 Host 判断是否跨源；当前文档还特别说明，两个头都没有时会放行。这一边界照顾了命令行客户端、服务间调用和一些不会发送来源头的请求。

所以，标题中的“拒绝没有 Origin”更准确的解释是：业务日志只打印了 Origin，却没有把 Sec-Fetch-Site、方法和最终响应来源一起记录。若请求携带 Sec-Fetch-Site: cross-site，即使 Origin 为空，也可能已经被浏览器跨源信号标记；若两个头都为空而仍是 403，就应该转向检查其他中间件。

用最小项目确认中间件放在哪里

接入时最好让保护器包在整个路由器外层，这样所有写接口都走同一条判定路径。下面的代码只展示接入方式；输出是读者可以预期的示例，不是某台机器的截图证据。

package main

import (
	"io"
	"log"
	"net/http"
)

func main() {
	mux := http.NewServeMux()
	mux.HandleFunc("/profile", func(w http.ResponseWriter, r *http.Request) {
		// 这个接口模拟会修改状态的请求，便于观察保护器边界。
		if r.Method != http.MethodPost {
			w.WriteHeader(http.StatusMethodNotAllowed)
			return
		}
		io.WriteString(w, "profile updated\\n")
	})

	protection := http.NewCrossOriginProtection()
	protection.SetDenyHandler(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		// 拒绝时记录真正参与判断的字段，避免只记录空 Origin。
		log.Printf("cross-origin denied method=%s fetch=%q origin=%q host=%q", r.Method, r.Header.Get("Sec-Fetch-Site"), r.Header.Get("Origin"), r.Host)
		http.Error(w, "cross-origin request denied", http.StatusForbidden)
	}))

	server := &http.Server{
		Addr:    ":8080",
		Handler: protection.Handler(mux), // 保护器包住全部路由。
	}
	log.Fatal(server.ListenAndServe())
}

出现 403 时按四个字段定位

先看响应是不是由你设置的 SetDenyHandler 产生。如果响应正文、状态码或日志格式完全不同，403 可能在反向代理、认证中间件或业务 handler 中提前返回。确认确实进入保护器后，再按下面顺序排查：

1. 方法：如果是 POST、PUT、PATCH 或 DELETE，先确认是否确实会修改状态；GET 被允许不代表 GET 可以安全地改数据。
2. Fetch Metadata：记录 Sec-Fetch-Site 的实际值。cross-site 是比“Origin 为空”更直接的线索，same-origin、same-site 和缺失值要结合部署拓扑解释。
3. Origin 与 Host：如果 Origin 存在，确认它是完整的 scheme://host[:port]，并与服务真正接收请求的 Host、代理转发配置一致。不要把路径拼进 Origin。
4. 来源链路：浏览器、API 网关和反向代理可能会改变或清理头部。把保护器前后各打一条结构化日志，确认不是网关把原请求换成了另一种形态。

如果前端确实在另一个可信站点发起写请求，可显式加入精确来源：

// 只允许实际使用的前端来源，协议、主机和端口都要写完整。
if err := protection.AddTrustedOrigin("https://app.example.com"); err != nil {
	log.Fatal(err) // 配置错误应在启动期暴露，而不是等请求失败。
}

不要把 AddInsecureBypassPattern("/api/...") 当作通用修复。它会让匹配路径的请求全部绕过跨源保护，适合经过单独认证和明确评估的边界；为了临时消除 403 而放开整组写接口，风险比补齐来源配置更大。

几个容易混淆的边界

没有 Origin 的 curl 请求会不会自动失败？按当前标准库文档，不会仅因缺少 Origin 而被 CrossOriginProtection 拒绝；如果失败，应检查其他中间件或是否主动设置了 Fetch Metadata 头。

加了 Origin 就一定能通过吗？也不一定。Origin 需要与 Host 的来源关系匹配；跨源写请求还要满足信任配置，格式错误、端口不一致都会留下拒绝线索。

为什么 OPTIONS 总是成功？它属于安全方法，保护器始终允许，但 CORS 预检的响应头仍需由应用或 CORS 中间件正确返回，不能把“预检成功”当成写请求已获授权。

排查这类问题时，我现在会先看完整的请求判定字段，再决定是补 AddTrustedOrigin、修代理转发，还是检查外层 403。只盯着一个空的 Origin 日志，很容易把真正的跨源信号和业务拒绝混在一起。