[Bug] Bridge security defaults are weaker than documented when token is unset

[xukp20]

cc-connect Version

Current main (reviewed on 2026-04-01)

Operating System

Linux (Ubuntu/Debian)

Agent Type

Other

Platform

N/A

Installation Method

Build from source

Bug Description

The current Bridge implementation appears to have weaker security defaults than the documentation suggests.

According to the docs/config examples:

• Bridge token is described as required
• all Bridge connections are described as requiring token authentication

However, in the current implementation:

1. if bridge.token is unset, authentication silently becomes allow-all
2. WebSocket CheckOrigin is always true
3. the Bridge server listens on :9810 by default (all interfaces)

This means that enabling [bridge] without setting token does not fail closed. Instead, both the Bridge WebSocket endpoint and the Bridge REST session endpoints become effectively unauthenticated for any client that can reach the port.

So the problem is not just documentation mismatch; it is also a risky default behavior for a
network-facing endpoint.

Steps to Reproduce

1. Configure Bridge without a token:

[bridge]
enabled = true
port = 9810
# token intentionally omitted

2. Start cc-connect
3. Make a request to a Bridge REST endpoint without any token, for example:

curl -i "http://127.0.0.1:9810/bridge/sessions"

4. Observe that the request is not rejected as unauthorized.
   Instead, it proceeds into normal handler logic and returns a business error such as:

• 400 session_key query parameter is required

5. Also connect to the Bridge WebSocket endpoint without any token and complete the normal register handshake. The connection is accepted because authenticate() returns true when the configured token is empty.

Expected Behavior

One of the following should happen when [bridge] is enabled:

• Bridge refuses to start unless token is set, or
• Bridge defaults to a clearly explicit local-only / insecure-dev-only mode, or
• Bridge requires an explicit opt-in flag before allowing unauthenticated access

In addition:

• WebSocket origin checks should not always be disabled
• Bridge security behavior should match the documentation

Actual Behavior

Current main behaves as follows:

• documentation says Bridge token is required
• runtime authentication allows all requests when bridge.token == ""
• WebSocket CheckOrigin always returns true
• server binds to :9810 by default

So Bridge can become an unauthenticated network-facing endpoint if enabled without a token.

Configuration (config.toml)

  [bridge]
  enabled = true
  port = 9810
  # token omitted

Logs / Error Output

  # Example REST call without token:
  curl -i "http://127.0.0.1:9810/bridge/sessions"
  # The request is not rejected with 401.
  # It reaches normal handler logic instead.

Additional Context

Relevant code:

• core/bridge.go
  • CheckOrigin: func(r *http.Request) bool { return true }
  • authenticate() returns true when bs.token == ""
  • Bridge server listens on :9810

Relevant docs/config examples:

• config.example.toml
  • token is documented as required
• docs/usage.md
  • “All Bridge connections require a token”
• docs/usage.zh-CN.md
  • “所有 Bridge 连接需要 token 认证”

This looks like a combination of:

• documentation/implementation mismatch
• insecure fail-open behavior when token is omitted
• overly permissive WebSocket origin policy

Possible directions:

• require non-empty token when Bridge is enabled
• or introduce an explicit insecure/local-dev mode instead of silently allowing all access
• make WebSocket origin checks configurable instead of unconditional true

[github-actions]

👋 Thanks @xukp20 for opening this issue! We'll take a look soon.

[chenhg5]

感谢详细的安全分析！

这是一个重要的安全问题，我们已标记为 P0 优先级 并安排修复。

修复方向：

1. 当 Bridge 启用时，要求 token 必须设置
2. 或引入明确的 local-dev 模式
3. 使 WebSocket origin 检查可配置

我们会在后续版本中解决这个安全问题。