Skip to content

Archive

WebSocket

5 articles
Cloud Computing 19 Sep 2026 6 min read

WebSocket Lifecycles in Cloudflare Workers: Upgrade, Coordination, and Hibernation

A Cloudflare Worker can terminate a WebSocket connection directly. The harder architectural question appears after the upgrade succeeds: where does connection state live, which process coordinates multiple clients, and what remains valid when the runtime is no longer in memory? Those are separate boundaries: HTTP request | | Upgrade: websocket v Worker | +-- one independent connection | +-- shared room / session / presence | v Durable Object | v optional hibernation Treating all of them as “WebSocket support” hides the behavior that matters most in production.

Software Engineering 19 Sep 2026 8 min read

FCM Is a Wake-Up Path, Not a Real-Time Transport

FCM Is a Wake-Up Path, Not a Real-Time Transport A mobile application can maintain a WebSocket while it is active and still need Firebase Cloud Messaging when the operating system suspends it. Those mechanisms solve different failure conditions. WebSocket, MQTT, and SignalR assume that a client can participate in a live communication session. FCM is useful precisely when that assumption no longer holds: the application may be backgrounded, its process may not be running, or its persistent connection may have disappeared.

Cybersecurity 16 Sep 2026 7 min read

WebSocket Origin Checks Keep Browser Sessions Inside an Explicit Trust Boundary

A user can be signed in to a WebSocket-backed application while browsing an unrelated site in another tab. JavaScript on that unrelated site can attempt a WebSocket connection to the application’s endpoint. If the browser attaches credentials applicable to the handshake and the server upgrades the connection without checking the initiating origin, the new message channel can inherit authenticated authority that the page itself was never meant to receive. This boundary differs from ordinary cross-origin fetch() handling. WebSocket establishes its own protocol channel through an HTTP opening handshake, and the server has to decide whether the browser origin named in that handshake is permitted to create the channel. CORS response policy is not a substitute for that decision.

Cybersecurity 13 Sep 2026 9 min read

WebSocket Upgrades Need Their Own Origin Policy

WebSocket Upgrades Need Their Own Origin Policy A WebSocket endpoint can sit behind the same hostname, TLS certificate, session cookie, and reverse proxy as an ordinary web application while obeying a different browser security model. The connection begins as HTTP, but once the upgrade succeeds, the familiar request-response controls around application endpoints no longer describe the full security boundary. That gap matters most when a browser automatically attaches credentials to the handshake. A hostile site may be able to initiate a WebSocket connection toward another origin. If the target service accepts the upgrade based only on a valid session cookie, the attacker’s page can gain a bidirectional channel operating with the victim’s authority. The browser’s same-origin restrictions on reading ordinary cross-origin HTTP responses do not provide the same protection for WebSocket traffic.

Cybersecurity 11 Sep 2026 9 min read

Validate WebSocket Origins Before Accepting Browser Connections

A WebSocket connection can stay open for minutes or hours and carry commands in both directions. If a browser automatically attaches an authenticated session to the opening handshake, a hostile web page may be able to start that connection in the user’s browser unless the server checks which site initiated it. That creates a cross-site trust problem. The user can be signed in to app.example, visit another site in a separate tab, and still have the browser make requests that involve credentials associated with app.example. A WebSocket server that accepts the handshake based only on those credentials can give an untrusted page access to an authenticated channel.