fix: Implement WebSocket origin checking in production

[salignatmoandal]

What

In production, WebSocket connections are now restricted to allowed origins only. In development, all origins are still accepted (no change for local dev).

Why

Previously, the server accepted WebSocket connections from any origin. That could allow a third-party site to open a WebSocket to your SuperPlane instance using the user's cookies. Restricting origins in production reduces that risk and aligns with common security practice for WebSockets.

How

• allowedWebSocketOrigins() builds the list of allowed origins:
  • In development (APP_ENV=development): returns no list → all origins accepted (unchanged behavior).
  • In production: uses WEBSOCKET_ALLOWED_ORIGINS if set (comma-separated), otherwise derives a single origin from BASE_URL (scheme + host).
• The WebSocket CheckOrigin callback now allows a connection only when:
  • there is no restriction list (dev / fallback), or
  • the request’s Origin header is in the allowed list.

Configuration

• BASE_URL: In production, the origin derived from this URL is allowed (e.g. https://app.example.com → https://app.example.com).
• WEBSOCKET_ALLOWED_ORIGINS (optional): Comma-separated list of origins when you need multiple (e.g. https://app.example.com,https://dashboard.example.com).
• No change needed for local development; all origins remain accepted when APP_ENV=development.

[cursor]

Missing Origin header blocks non-browser WebSocket clients

Medium Severity

When allowedOrigins is configured (production), connections without an Origin header are rejected. The gorilla/websocket default behavior is to accept connections when the Origin header is absent, because non-browser clients (CLI tools, server-to-server) typically don't send it. The Origin header is a browser-only CSRF mechanism, so rejecting its absence blocks legitimate programmatic clients without any security benefit — non-browser clients can trivially forge the header anyway.

 

[shiroyasha]

Hey @salignatmoandal 🙌 I like to idea of this PR.

I would like to see some small code cleanup before we merge it.

1/ Lets create a new file dedicated to this
2/ Instead of adding low level details in the main server code, lets extract the logic into the other file as much as possible
3/ In what scenarios we want anything other than BASE_URL? 🤔 Do we have a real use for that additional environment variable?

A closure could work well for this use case. e.g.:

// pkg/server/websocket_origin_checker.go

func WebsocketOriginChecker() func(*http.Request) bool {
  var allowedOrigins
  // calculate allowed origins here ...

  return func(r *http.Request) bool {
    // verify here    
  }
}

// pkg/server/server.go

server := &Server{
  upgrader: &websocket.Upgrader{
    CheckOrigin: WebsocketOriginChecker()
  }
}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Case-sensitive origin comparison breaks with non-lowercase BASE_URL

Low Severity

The origin comparison origin == allowedOrigin is case-sensitive, but RFC 6454 requires ASCII case-insensitive origin comparison, and gorilla/websocket's own default checkSameOrigin uses equalASCIIFold. Since Go's url.Parse does not normalize scheme or host to lowercase, a BASE_URL like HTTPS://App.Example.com would produce an allowedOrigin with uppercase characters, while browsers always send lowercase Origin headers — causing all WebSocket connections to be rejected in production.

 

[salignatmoandal]

Yep, I followed that approach.

I moved the WebSocket origin logic to a dedicated file, and server.go now only wires CheckOrigin via a closure (newWebSocketCheckOrigin(appEnv, baseURL)), so the low-level details are out of the main server setup.

I also simplified the config to rely on BASE_URL in production, while keeping development unrestricted.

[cursor]

You have used all of your free Bugbot PR reviews.

To receive reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.