golang如何配置安全的CORS策略_golang安全CORS策略配置要点-Golang-PHP中文网

生产环境禁用 access-control-allow-origin: "*" 是因浏览器规范禁止其与 credentials 或 set-cookie 共存，否则 cors 请求静默失败；应使用 gorilla/handlers.cors 配置具体域名白名单、显式开启凭据与暴露头，并确保 nginx 透传响应头。

golang如何配置安全的cors策略_golang安全cors策略配置要点

为什么直接设 `Access-Control-Allow-Origin: "*"` 在生产环境会出问题

因为浏览器规范强制要求：只要响应中包含 Access-Control-Allow-Credentials: "true"（比如前端用了 credentials: 'include'），或后端尝试写入 Set-Cookie，Access-Control-Allow-Origin 就不能是 "*"。否则控制台报错：The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*'，且请求静默失败。

常见误操作：

开发时设了 "*"，上线后前端加了 token 或 cookie，CORS 突然失效
用 gorilla/handlers.CORS 时传了 AllowCredentials: true 和 AllowedOrigins: ["*"]，二者冲突导致中间件自动禁用凭据支持
没校验 Origin 请求头，直接回写原值，被恶意站点伪造 Origin 头绕过限制

用 `gorilla/handlers.CORS` 配置生产可用的策略

这是目前最稳、无依赖、更新活跃的通用方案。关键不是“怎么加”，而是参数怎么配不踩坑：

handlers.AllowedOrigins([]string{"https://app.example.com", "http://localhost:3000"})：必须列具体协议+域名+端口，不支持 https://*.example.com 或路径
handlers.AllowCredentials()：仅当需要 cookie/token 时开启，且必须和上面的 AllowedOrigins 同时存在，不能单独开
handlers.ExposedHeaders([]string{"X-Total-Count", "X-Request-ID"})：前端 JS 要读取的自定义响应头必须显式列出，否则 response.headers.get("X-Total-Count") 返回 null
handlers.MaxAge(3600)：单位是秒，设太大（如 86400）会导致预检缓存过期后仍沿用旧策略，调试困难

示例片段：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

import "github.com/gorilla/handlers"

r := mux.NewRouter()
// ... 注册路由
handler := handlers.CORS(
    handlers.AllowedOrigins([]string{"https://myapp.com", "http://localhost:3000"}),
    handlers.AllowCredentials(),
    handlers.ExposedHeaders("X-Total-Count"),
    handlers.MaxAge(3600),
)(r)

手动写中间件时 header 设置时机和顺序很关键

Go 的 http.ResponseWriter 对 header 写入非常敏感：一旦调用 w.WriteHeader() 或开始写响应体（w.Write()），再设 header 就无效。所以必须在所有逻辑前统一设置。

OPTIONS 请求必须提前拦截并返回 http.StatusOK，不能让它落到后续 handler
Access-Control-Allow-Origin 和 Access-Control-Allow-Credentials 必须成对出现（如果开了凭据）
不要在多个地方重复 w.Header().Set()，容易漏、覆盖、顺序错
若需动态 origin 白名单（如 SaaS 多租户），必须自己解析 r.Header.Get("Origin") 并比对 map 或正则，gorilla/handlers.CORS 不支持回调式匹配

GIN 框架里别在 handler 里直接改 `c.Writer.Header()`

GIN 的 c.Writer 是封装对象，部分底层行为（尤其是 OPTIONS 响应的 status code 和 header 合并）只在中间件链路中完整触发。在某个路由 handler 里写 c.Writer.Header().Set("Access-Control-Allow-Origin", ...)，大概率导致预检失败或 header 丢失。