Cross-Site WebSocket Hijacking is an attack where a browser is tricked into opening a WebSocket connection to a trusted site and sending messages as the logged-in user. The risk arises when servers trust browser cookies for authentication without validating the connection origin, enabling unauthorized actions or data exposure.
How Cross-Site WebSocket Hijacking Works
Cross-Site websocket hijacking happens when a browser can be induced to open a WebSocket to a trusted origin and the server accepts the connection based on ambient browser authentication alone. The key weakness is not the WebSocket protocol itself, but the failure to treat the handshake as a sensitive cross-origin action.
Unlike a simple HTTP request, a WebSocket connection can stay open and carry an ongoing stream of messages. That makes the initial trust decision especially important: if the server does not validate the request origin, an attacker-controlled page may be able to create a live authenticated channel using the victim’s browser session.
Why It Becomes Dangerous
The danger is that the attacker is not necessarily stealing the user’s password or session cookie. Instead, they are borrowing the browser’s existing trust relationship and using it to send actions that look legitimate to the application. That can expose data, trigger state-changing operations, or let an attacker interact with a backend service as if they were the logged-in user.
This is especially serious for applications that use WebSockets for privileged workflows, admin consoles, chat, collaboration tools, or real-time account actions. If the server assumes “browser sent a cookie, so the connection must be safe,” the origin boundary has effectively disappeared.
Where Exposure Usually Comes From
Organisations typically become exposed when authentication is tied to browser cookies but the WebSocket handshake is not checked for a trusted Origin value. Weaknesses also appear when development teams focus on message-level validation but forget that the connection itself must be authorised before any application traffic is accepted.
Discovery is usually straightforward for defenders: review application inventory, identify which services accept WebSocket traffic, and check whether those endpoints are reachable from the internet or from untrusted web content. Vendor guidance and application security testing notes are useful here, and a broader review of common web attack patterns is available in the Web Application Attacks Guide.
Detection and Response After Suspicious Use
Detection is often harder than prevention because the traffic may look like normal authenticated activity. Useful indicators include unexpected WebSocket sessions from unusual referrers, abnormal message sequences, or sensitive actions being performed without a corresponding user journey in the UI.
If abuse is suspected, review server logs for handshake metadata, message timing, and origin values, then determine whether any privileged actions, data reads, or account changes occurred through that channel. The most important post-incident question is whether the application trusted the browser session too broadly, because that determines whether similar endpoints may also be exposed.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service Security | WebSocket handshakes and message flows are web service security concerns. |
| Recommendation — Verify origin handling and access checks on WebSocket endpoints as part of web service security. | ||
| NIST SP 800-53 Rev 5 | AC-10 — Concurrent Session Control | Persistent browser sessions and live connections create session control concerns. |
| IA-2 — Identification and Authentication (Organizational Users) | The attack abuses authenticated browser sessions that the server accepts without stronger handshake validation. | |
| Recommendation — Limit and monitor active sessions that can drive sensitive WebSocket activity. Ensure authenticated users are revalidated at connection setup before permitting sensitive WebSocket actions. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | The issue arises when a server trusts browser authentication on the WebSocket channel without sufficient validation. |
| Recommendation — Harden WebSocket authentication so a browser session alone cannot establish trusted access. | ||
| MITRE ATT&CK | T1185 — Browser Session Hijacking | The technique abuses a victim browser session to perform actions through a trusted channel. |
| Recommendation — Hunt for browser-mediated hijacking patterns and unusual authenticated session use. | ||
Practitioner Guidance
Why practitioners should care: WebSocket security needs the same trust-boundary discipline as other browser-facing endpoints. If a connection can be opened cross-site and the server accepts it purely because cookies are present, the application has not actually authenticated the request origin, only the browser session.
Common misunderstanding: Many teams assume WebSocket traffic is safe once HTTPS is in place. Transport security protects the channel, but it does not stop a malicious site from causing the victim’s browser to initiate a trusted connection unless the server validates the handshake origin and the application’s own access rules.
Practitioner takeaway: Treat the opening handshake as a security control point, not a formality. If a WebSocket endpoint performs sensitive actions, it should be designed and tested with explicit origin validation and clear session-boundary checks.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org