fix(bridge): refuse browser-driven and DNS-rebound requests

[claudiusthebot]

Summary

The native bridge sent Access-Control-Allow-Origin: * on every response, answered OPTIONS 204 unconditionally, and never read Host or Origin. Combined with its default posture — loopback bind, no token, and authState() returning "ok" for every route when no token is set — any website the user visits could drive the agent.

Concretely, a visited page could:

• read /chats, /history, /logs, /config, /devices — transcripts, daemon logs, and the GPS coordinates of every registered phone;
• POST /send, which runs an agent turn with full tool access — arbitrary code execution on the host.

Port discovery is trivial: /health is unauthenticated and self-describes as "app":"talon-bridge".

Preconditions are just the documented single-machine setup: frontend: "native", native.host defaulting to 127.0.0.1, no native.token (a token is minted only for a non-loopback bind, index.ts:1206-1210).

The fix — two independent guards

Origin. Browsers attach Origin to cross-origin requests and page scripts cannot forge it; native clients (Electron main, Flutter, curl, talon-node) omit it entirely. So a non-allowlisted Origin means a web page is driving us → 403. Native clients are completely unaffected. Genuine browser clients go in the new native.allowedOrigins, echoed back explicitly. The wildcard is gone, including on the preflight — a 204 that green-lights any origin is the permission the browser was asking for.

Host. A hostname that resolves to 127.0.0.1 makes the request same-origin, so no Origin is sent and the check above never fires. Host is now pinned to loopback spellings or the configured bind. A wildcard bind (0.0.0.0) skips this — there the bearer token is the control.

Also fixed: native.token: "" silently disabled auth

nativeCfg.token ?? mint() treats an empty string as a configured token, so the auto-mint never fired and a 0.0.0.0 bind served the LAN unauthenticated with TLS up — looking hardened. Easy to hit from "token": "${BRIDGE_TOKEN}" with the variable unset. Empty now counts as absent.

Implementation note

The grant is applied via res.setHeader once in handle() rather than inside corsHeaders(), so it survives all ~8 writeHead sites without threading the origin through each one.

This is easy to get subtly wrong: my first attempt set it only on the preflight, so an allow-listed origin passed CORS and then couldn't read a single response. There's a test pinning exactly that.

Verification

Against a live BridgeServer over raw HTTP (fetch forbids setting Host, which is half of what needed testing):

[default: loopback, no token]
   OPTIONS /send evil-origin        403
   GET /chats evil-origin           403
   POST /send evil-origin           403
   GET /chats native (no Origin)    200
   GET /chats DNS-rebind Host       403
   GET /health native               200

agent invocations from a web origin: 0

10 new tests. Full non-integration suite passes (4070). tsc --noEmit and oxlint clean.

Not addressed here

The same audit surfaced other mesh issues worth separate PRs — every device sharing one bridge token, completeCommand accepting a result with no deviceId, device commands broadcast to all SSE clients including transfer tokens, and unbounded registry growth. Happy to take those next; this PR is scoped to the remotely-reachable one.

🤖 Generated with Claude Code