WebSocket Hijacking in AI Agents

WebSocket connections provide persistent, bidirectional communication channels between agents and their supporting services. Unlike HTTP requests that are evaluated individually, WebSocket connections remain open, creating opportunities for hijacking that bypass per-request safety checks.

The Risk

Many agent architectures use WebSockets for: streaming model responses, real-time tool execution, inter-agent communication, and live monitoring dashboards. These long-lived connections often bypass the request-level security that protects HTTP endpoints.

Attack Vectors

Cross-Site WebSocket Hijacking (CSWSH) occurs when a WebSocket endpoint does not validate the Origin header. An attacker's web page can open a WebSocket connection to your agent's backend, sending commands as if they were the legitimate client.

Message injection targets the WebSocket message stream. If the connection between an agent and its tool server is not authenticated per-message, an attacker who gains network access can inject messages into the stream.

Upgrade hijacking exploits the HTTP-to-WebSocket upgrade process. If the upgrade request is not properly authenticated, an attacker can establish a WebSocket connection without valid credentials.

Session riding uses an authenticated WebSocket connection to send attacker-controlled messages. If the agent's WebSocket accepts messages from the client without re-validating authorization, an XSS vulnerability in the application can be leveraged to send arbitrary commands to the agent.

Defense Strategies

Validate Origin headers on WebSocket upgrade requests. Only accept connections from your own domains.

Authenticate WebSocket connections during the upgrade handshake. Require a valid token in the query string or the first message. Authensor's API key system can authenticate WebSocket connections.

Authenticate individual messages. Do not trust a message just because it arrived on an authenticated connection. Include a signature or token with each message for high-security channels.

Apply policy checks per message. Route WebSocket messages through Authensor's policy engine the same way HTTP requests are evaluated. The persistent connection should not bypass safety checks.

Implement message rate limiting. WebSocket connections can receive messages much faster than HTTP. Rate limit per connection to prevent denial-of-service through message flooding.

Monitoring

Log WebSocket connection lifecycle events (open, close, error) and message counts. Alert on connections with unusually high message rates or connections from unexpected origins. Authensor's audit trail records actions triggered through WebSocket messages, maintaining the same visibility as HTTP-triggered actions.