不配 CheckOrigin 或写死 return true 会导致 WebSocket 接口裸奔公网，任何网站均可利用用户身份连接；gorilla/websocket 默认 checkSameOrigin 严格校验 Origin 与 Host 完全一致，生产中常因前后端域名不同而失败，但安全合理。
直接说结论：不配 CheckOrigin 或者写死 return true 就等于把 WebSocket 接口裸奔在公网，任何网站都能用用户身份连上来——这不是“开发方便”，是给攻击者递刀。
gorilla/websocket 的 CheckOrigin 默认行为到底做了什么
当你没显式设置 Upgrader.CheckOrigin 时，gorilla 会用内置的 checkSameOrigin 函数，它只做一件事：比对请求头里的 Origin 和 Host 是否完全一致（协议 + 域名 + 端口）。比如客户端从 https://admin.example.com 发起连接，后端 Host 是 api.example.com:443，哪怕同域、同证书，也会被拒绝。
这个逻辑在生产环境几乎总是失败，因为前端和后端域名天然不同；但它在安全上是合理的——防止恶意页面伪造 Origin 发起连接。
常见错误现象：
- 本地开发时
file://打开 HTML，Origin是null或空字符串，直接 403 - Vite/HMR 代理到
http://localhost:8080，但后端 Host 是example.com，校验失败 - 前端部署在 CDN 或多级反代后，
Origin没被透传，或被篡改
怎么写一个既安全又可用的 CheckOrigin 函数
核心原则：白名单 + 协议容错 + 开发环境可区分。不要用字符串前缀匹配（如 strings.HasPrefix(origin, "https://example.com")），那会放行 https://example.com.evil.com 这类子域名劫持。
实操建议：
- 白名单必须是完整、明确的
Origin字符串，包括协议和端口（如https://app.example.com、http://localhost:3000） - 允许空
Origin仅限开发环境，通过环境变量（如ENV=dev）控制，线上必须关闭 - 如果用了反向代理（Nginx/Cloudflare），确保它透传了原始
Origin头，而不是覆盖成自己的 Host - 避免用正则匹配域名——易出错且难审计；用精确字符串比对更可控
示例代码片段：
var wsUpgrader = websocket.Upgrader{
CheckOrigin: func(r *http.Request) bool {
origin := r.Header.Get("Origin")
if origin == "" {
return os.Getenv("ENV") == "dev"
}
allowed := []string{
"https://app.example.com",
"https://admin.example.com",
"http://localhost:3000",
"http://127.0.0.1:3000",
}
for _, a := range allowed {
if origin == a {
return true
}
}
return false
},
}
Origin 校验失效的典型场景和排查点
即使代码写了白名单，仍可能被绕过。关键排查点：
- 浏览器端 JavaScript 无法手动设置
Origin头——它由浏览器自动注入，值永远等于当前页面的document.origin。所以测试时务必用真实页面打开，别双击 HTML 文件 - 移动端 WebView 或 Electron 应用可能默认不发
Origin，需检查客户端 SDK 或封装层是否禁用了该头 - 某些老旧 Android WebView 或定制浏览器会发送非法
Origin（如file://、about:blank），这类请求应明确拒绝，不能靠“开发模式”兜底 - 如果你的服务同时支持浏览器和非浏览器客户端（如 CLI 工具、IoT 设备），它们根本不会带
Origin头——这时不应依赖CheckOrigin做鉴权，而应在 Upgrade 前完成 Token 或证书认证
真正容易被忽略的是：Origin 校验只是第一道门，它防不住已登录用户的会话复用。所有敏感操作（如发消息、删数据）仍需在 WebSocket 连接建立后，基于用户身份做细粒度权限判断——校验 Origin 不等于完成了认证。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
