Go websocket 升级前怎样校验来源

我在把一个 HTTP 接口改成 WebSocket 时，最容易忽略的不是连接怎么读写，而是“谁可以发起升级”。浏览器会在握手请求里带上 Origin，真正决定是否升级的服务端应该在调用 Upgrade 前完成来源判断。

对 Go 项目来说，推荐把允许的来源写成精确白名单交给 websocket.Upgrader.CheckOrigin：匹配 scheme 和 host，拒绝空值、路径异常以及未登记的站点。这样来源策略属于握手边界，而不是连接建立后才补救。

核心做法是：只允许明确登记的 Origin，校验失败就让 Upgrade 返回 403；不要把 Host 当成来源，也不要用“全部返回 true”换取联调方便。

先分清 Origin、Host 和 101 握手

WebSocket 通常先从 HTTP/1.1 请求开始，客户端用 Connection: Upgrade 和 Upgrade: websocket 邀请服务端切换协议。服务端接受后才返回 101 Switching Protocols，连接随后进入双向通信。

Host 表示请求要到达哪个服务地址，Origin 表示发起浏览器脚本所属的来源。它们在同站点场景里可能相同，但不能因此把 Host 比较当成来源授权。Gorilla 文档也明确把 Origin 策略交给 CheckOrigin。

官方地址：https://pkg.go.dev/github.com/gorilla/websocket

把校验写进 Upgrader.CheckOrigin

我更倾向于让白名单保存完整的来源串，再解析后只比较 scheme 和 host。这样不会把 https://app.example.com.evil.test、带路径的伪来源或大小写处理不清的字符串误当成合法站点。

package main

import (
    "net/http"
    "net/url"

    "github.com/gorilla/websocket"
)

var allowedOrigins = map[string]struct{}{
    "https://app.example.com": {},
    "https://admin.example.com": {},
}

var upgrader = websocket.Upgrader{
    CheckOrigin: func(r *http.Request) bool {
        rawOrigin := r.Header.Get("Origin")
        if rawOrigin == "" {
            // 浏览器来源为空时不默认放行，非浏览器客户端需走单独授权策略。
            return false
        }

        origin, err := url.Parse(rawOrigin)
        if err != nil || origin.Scheme == "" || origin.Host == "" {
            // 解析失败或缺少协议/主机时，不能把字符串猜成合法来源。
            return false
        }
        if origin.Path != "" || origin.RawQuery != "" || origin.Fragment != "" {
            // Origin 不应携带路径、查询参数或片段，避免出现伪造的匹配形式。
            return false
        }

        canonical := origin.Scheme + "://" + origin.Host
        _, ok := allowedOrigins[canonical]
        // 只有精确登记的来源才允许继续握手。
        return ok
    },
}

func wsHandler(w http.ResponseWriter, r *http.Request) {
    conn, err := upgrader.Upgrade(w, r, nil)
    if err != nil {
        // CheckOrigin 失败时 Upgrade 已写入错误响应，这里只记录并结束处理。
        return
    }
    defer conn.Close()

    // 连接建立后的读写、身份认证和消息权限仍需单独设计。
}

这里的关键不是把白名单写成 map，而是把判定点固定在 Upgrade 内部：返回 false 时，握手不会成功。Gorilla 的安全默认值也会在 Origin 存在且其 host 与请求 Host 不同的情况下拒绝，但生产项目通常仍应显式列出允许的站点，尤其是前后端分离和多域名部署时。

几个看似省事的写法，代价都在握手边界外

第一种反例是 CheckOrigin: func(*http.Request) bool { return true }。它适合极短的本地联调，不适合作为正式策略，因为所有浏览器来源都被当成可接受来源。

第二种反例是只比较 r.Host。Host 只能说明请求抵达的主机，不能证明哪个页面触发了浏览器连接；校验来源时应读取 r.Header.Get("Origin")，并把它与受控白名单比较。

第三种反例是继续使用已弃用的包级 websocket.Upgrade，然后忘记补来源检查。该入口不会替应用执行 Origin 校验。若前面还有反向代理，还要确认代理传递到应用的 Host 与 Origin 语义没有被错误改写；来源白名单不能靠“猜一个 Host”来修补。

上线前我会保留的判断清单

• 允许列表是否包含完整的 scheme 和 host，而不是模糊后缀匹配？
• Origin 缺失、解析失败、带路径或未登记时，是否在 Upgrade 前拒绝？
• 是否使用 websocket.Upgrader 的 CheckOrigin，而不是忘记校验的旧入口？
• 来源校验是否与登录态、Token、消息级权限分开？Origin 只是浏览器来源信号，不能代替用户身份认证。

我的取舍是：白名单宁可先收紧，再按实际前端域名补充；把来源策略写在升级边界，后续再处理连接身份和消息权限。这样排查“为什么 403”时，问题会落在一个清晰的函数上，而不是散落在连接读写逻辑里。

相关问题

没有 Origin 的 WebSocket 客户端一定不可信吗？

不一定。非浏览器客户端可能不会自动发送 Origin，但这不等于它已经通过授权。可以为这类客户端设计独立的认证入口或令牌策略，不要为了兼容而无条件放行空值。

Origin 校验通过后还需要鉴权吗？

需要。Origin 只回答“请求来自哪个网页来源”，不能回答“当前用户是谁、是否有权访问这条连接”。登录态、令牌和消息权限仍要在连接建立或业务消息处理中完成。