Check browser origins before WebSocket upgrades
Define a WebSocket handshake policy for browser and machine clients. Test exact origins, missing origin handling, authentication, and proxy behavior.
A WebSocket endpoint needs its own handshake review. Do not assume that the HTTP API's CORS configuration governs it. Identify the browser clients allowed to open a connection and the credentials the browser supplies during the upgrade.
OWASP recommends explicit Origin validation for WebSocket handshakes. Origin is a browser-context signal, not a replacement for authentication. Non-browser clients can supply headers and need an appropriate credential policy of their own.
Separate client classes
List each intended browser origin with scheme, host, and port. Record machine clients separately instead of allowing any missing Origin request to use the browser's session-cookie path. Decide how development and preview origins are managed.
| Handshake case | Authentication | Expected result |
|---|---|---|
| Approved browser origin | Valid test session | Upgrade under the user's allowed scope |
| Unapproved controlled origin | Same test session | Refuse before opening the channel |
| Approved origin | Missing or expired session | Refuse authentication |
| Missing Origin | Machine credential policy | Apply the explicitly supported client rule |
| Similar hostname or wrong port | Valid test session | Refuse unless separately approved |
Keep rejection before connection registration so an unauthorized attempt cannot join a room or receive an initial message.
Test through the normal proxy path
Use an approved browser fixture to initiate real upgrades. Capture the handshake result and whether any application message arrives. Check the edge and reverse proxy configuration, because an application-only test may not reflect the headers delivered to the server.
Exercise a valid connection as the positive control. Also test reconnect behavior after session expiry and after an origin configuration change. Avoid opening large numbers of connections; a small controlled matrix is enough to test policy matching.
Record what the handshake does not prove
An accepted connection does not authorize every later message or subscription. Keep action-level checks and revocation behavior in the message review. Likewise, a rejected browser origin does not protect a machine endpoint that accepts anonymous commands.
Store the origin list, credential mode, proxy route, browser version, and observed outcome. Remove stale preview origins when their environments are retired. Recheck this record whenever the application introduces an embedded client or a new public hostname. The intended result is a clear connection-admission boundary, followed by a separately enforced message-permission boundary.
Find the gaps before your next launch
Use the release checklist to identify changed security boundaries and missing evidence. Discuss the application paths you want reviewed before launch.