fix(wss): add OriginPatterns to prevent browser slot exhaustion (PILOT-285)

[matthew-pilot]

What

Add OriginPatterns: []string{"pilot://*"} to the websocket.Accept call in wss/server.go:336.

Why

The beacon WSS server accepts WebSocket upgrades from any browser origin. A malicious website can open WebSocket connections and exhaust the MaxPeers slots before the Ed25519 authentication challenge completes. These CSRF-style WS connections are rejected at the challenge stage but still consume a connection slot.

Fix

OriginPatterns: ["pilot://*"] causes the nhooyr.io/websocket library to check the Origin header at upgrade time. Non-browser clients (Go/Python/Node SDKs) do not send an Origin header, so they are unaffected. Browser clients with an Origin header that doesn't match the pattern are rejected with HTTP 403 *before* consuming a slot.

Verification

go build ./...   # ✓
go vet ./...     # ✓
go test ./...    # ✓ all pass

Closes PILOT-285

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[matthew-pilot]

🦀 Matthew PR Check — #15 PILOT-285

Status

• State: OPEN · MERGEABLE ✅
• CI: 2/2 passing (test ✅, codecov/patch ✅)
• Canary: not-configured (beacon has no canary integration)
• Jira: PILOT-285
• Labels: none

Details

• Branch: openclaw/pilot-285-20260530-081819 → main
• Files: 1 (+2 −1) — wss/server.go
• Created: 2026-05-30 08:18 UTC
• Author: matthew-pilot

Verdict

CLEAN — small targeted fix, all CI green, mergeable. No labels or canary gates blocking.

[matthew-pilot]

🦀 Matthew Explains — #15 PILOT-285

What this does

Adds OriginPatterns: []string{"pilot://*"} to the websocket.Accept call in wss/server.go. This instructs the nhooyr.io/websocket library to validate the browser Origin header at WebSocket upgrade time — before a connection slot is consumed.

The problem

The beacon WSS server currently accepts WebSocket upgrade requests from any browser origin. A malicious website can open wss://beacon.pilotprotocol.com/ws connections and exhaust MaxPeers slots via CSRF-style WS connections. These connections are eventually rejected at the Ed25519 challenge stage — but only after consuming a slot, creating a denial-of-service vector.

The fix

With OriginPatterns: ["pilot://*"], the websocket library checks the Origin header during the HTTP→WS upgrade handshake:

• Browser clients sending an Origin that doesn't match pilot://* → rejected with HTTP 403 before slot allocation
• Non-browser clients (Go/Python/Node SDKs, CLI tools) → no Origin header, unaffected — upgrade proceeds normally
• Legitimate browser clients (e.g. dashboard, web-based tools using pilot:// origin) → pass the pattern check

Risk assessment

LOW — 2-line addition in a single file (wss/server.go). The change is a library-level configuration flag, not custom logic. Non-browser clients are unaffected. Browser-based clients that worked before will only be affected if they use a non-pilot:// origin, which is unlikely for Pilot Protocol tooling.

[matthew-pilot]

Status (auto)

• PR: open, mergeable · branch openclaw/pilot-285-20260530-081819 → main
• Canary: not run
• Jira: PILOT-285 — QA/IN-REVIEW (Teodor Calin)
• Last activity: 2026-05-30T08:24 UTC