Platform

Platform overview How it works Authorization testing Evidence & reports Private scanning Integrations

Solutions

Security agencies Product teams Regulated industries Partner programme

Learn

Blog Knowledge hub Compare

Resources

Pricing Documentation Help centre FAQ Security & data What we haven’t proved

Company

About Contact Careers Sign in to the platform Start a $199 pilot →

Home / Knowledge hub / WebSocket security

Knowledge hub

WebSocket security

Keeping long-lived, two-way connections from becoming an unchecked back door.

Illustration explaining WebSocket security

What it means

A WebSocket is a connection that stays open after the first request, so the browser and the server can send messages to each other at any time. Chat, live prices, notifications and collaborative editing all use them. It starts as an ordinary HTTP request and is then upgraded.

WebSocket security is the work of making that open channel as careful as your normal pages. The handshake can be checked once, but the messages that follow arrive without the usual request-by-request checks unless you add them yourself. That gap is where most WebSocket problems live.

Why it matters

Teams often protect their regular endpoints well and forget the socket beside them. A message handler that trusts whatever arrives can read another account's data, run an admin action, or accept input that would have been filtered anywhere else. The channel also stays open for hours, so one bad decision at the start lasts.

Browsers do not apply the same-origin policy to WebSocket connections, and they attach cookies to the handshake. A hostile page can therefore ask your server for a socket in a visitor's name unless you check where the request came from.

How it shows up

You meet it in live dashboards, chat, trading screens and support widgets. The repeating mistakes are a handshake that never checks the Origin header, authentication done once and never again, no check on who owns the room or record named in a message, and no limit on message size or rate.

Check the origin on the server, use wss:// so traffic is encrypted, and treat every message as untrusted input. Authorise each action as it arrives, expire or refresh sessions on long connections, and cap how much one client can send.

Questions people ask

WebSocket security, answered

Does the same-origin policy protect WebSockets?

No. Browsers will open a WebSocket to any origin, and send the visitor's cookies with the handshake. The server has to decide which origins it accepts.

That is why checking the Origin header matters.

What is cross-site WebSocket hijacking?

It is when a hostile website makes a visitor's browser open a socket to your site, using the visitor's cookies, and then reads or sends messages as that visitor. It works when the handshake relies on cookies alone and ignores the Origin header.

A check on the origin, or a token in the handshake, closes it.

Should we use ws or wss?

Use wss, which is WebSocket over TLS, the same way you use HTTPS for pages. Plain ws sends everything readable on the network.

Browsers may also block ws from a secure page.

Is authentication at connect time enough?

Rarely. The user could be signed out, lose a role or have a token revoked while the socket stays open. Check each message against current permissions, and close sockets when sessions end.

Re-check for sensitive actions.

How do we test a WebSocket?

Open the connection from a different origin, replay messages from one account on another, name records you do not own, and send oversized or malformed messages. Compare the results with the same actions over normal HTTP.

Any difference is worth a look.

Cyberlop mark

What does the open socket allow?

We test the handshake and the messages that follow, including one account naming another's records, and show the request and response that proved it. Book a pilot on one app.

Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.