Add WebSocket origin, session, workspace, and capability security #13

New issue

Closed

opened 2026-07-30 04:06:50 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-07-30 04:06:50 +00:00

(Migrated from github.com)

Problem

The WebSocket control-plane endpoint introduced in PR #3 accepts connections and commands without authentication, Origin validation, workspace authorization, message-size limits, or command capability checks.

Every event is broadcast to every connection regardless of workspace. This becomes both a data-isolation and correctness defect once more than one workspace or user session exists.

starlang.load also accepts client-supplied source and invokes the runtime loader, which must not be reachable through an unauthenticated local WebSocket endpoint.

Found during review of PR #3.

Required changes

Define a CLOG-issued session token or equivalent authenticated handshake.
Validate allowed WebSocket Origins.
Associate each connection with a principal/session and authorized workspace set.
Deliver events only to connections subscribed and authorized for the event workspace.
Enforce command capabilities, especially StarLang, actors, imports, exports, and network tools.
Add maximum message size, command timeout, and bounded per-connection rate limits.
Reject malformed or unauthorized requests with stable protocol errors.
Do not expose arbitrary Lisp evaluation.
Add structured security/audit records without logging secrets or full credentials.
Keep the default local-development flow usable while requiring explicit insecure-development configuration if authentication is bypassed.

Acceptance criteria

A connection from an unapproved Origin is rejected.
A connection without a valid session cannot issue privileged commands.
A client cannot read or mutate an unauthorized workspace.
Workspace events are not broadcast globally.
StarLang loading requires an explicit capability.
Tests cover unauthorized access, cross-workspace isolation, origin rejection, oversized messages, and capability denial.

Related PR: #3

## Problem The WebSocket control-plane endpoint introduced in PR #3 accepts connections and commands without authentication, Origin validation, workspace authorization, message-size limits, or command capability checks. Every event is broadcast to every connection regardless of workspace. This becomes both a data-isolation and correctness defect once more than one workspace or user session exists. `starlang.load` also accepts client-supplied source and invokes the runtime loader, which must not be reachable through an unauthenticated local WebSocket endpoint. Found during review of PR #3. ## Required changes - Define a CLOG-issued session token or equivalent authenticated handshake. - Validate allowed WebSocket Origins. - Associate each connection with a principal/session and authorized workspace set. - Deliver events only to connections subscribed and authorized for the event workspace. - Enforce command capabilities, especially StarLang, actors, imports, exports, and network tools. - Add maximum message size, command timeout, and bounded per-connection rate limits. - Reject malformed or unauthorized requests with stable protocol errors. - Do not expose arbitrary Lisp evaluation. - Add structured security/audit records without logging secrets or full credentials. - Keep the default local-development flow usable while requiring explicit insecure-development configuration if authentication is bypassed. ## Acceptance criteria - A connection from an unapproved Origin is rejected. - A connection without a valid session cannot issue privileged commands. - A client cannot read or mutate an unauthorized workspace. - Workspace events are not broadcast globally. - StarLang loading requires an explicit capability. - Tests cover unauthorized access, cross-workspace isolation, origin rejection, oversized messages, and capability denial. Related PR: #3