System and boundaries
WebSocket creates a long-lived bidirectional channel after an HTTP handshake and upgrade. The access system must protect the handshake, connection identity, message authorization, lifetime, backpressure, and shutdown.
Request and connection flow
The client sends an authenticated upgrade request. The gateway authorizes the route and proxies the handshake. After acceptance, client and server exchange frames until closure. The application must authorize message-level resources and actions.
Identity and state
Bind the accepted connection to the authenticated subject, route, origin, protocol, and initial policy. Define idle and maximum lifetime, reauthentication or reconnect behavior, revocation, message size, rate, and correlation evidence.
Failure and residual risk
Policy can change while a connection remains open. A valid route can carry unauthorized application messages. Cross-site WebSocket use, origin mistakes, unbounded messages, slow clients, reconnect storms, and direct endpoints can create security or availability failures.
Pomerium boundary
Pomerium authorizes a WebSocket route when the connection starts. It does not terminate an established connection only because policy later changes. The upstream owns message-level authorization and safe protocol behavior.
Evaluation checklist
- Which HTTP request and policy authorize the initial upgrade?
- How are subject and route identity bound to the live connection?
- Which application messages require separate authorization?
- What are the lifetime, revocation, reconnect, size, and rate rules?
- Can a client bypass the protected upgrade path?
