I've been reading some posts about WebSockets security, and a few of them mention to use the Origin header for helping secure the connection. For example this one https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html.

However, I'm really doubtful about the benefits it's going to provide. Why would I need to use the Origin header? Or better said, how would I use the Origin header for something useful?

  • Is this question more about why cross-site Websockets can be a problem at all or more about how the Origin header can be used to prevent this problem? Commented Feb 25, 2016 at 9:39
  • @SteffenUllrich rather the latter. I'm mostly interested in how it helps during the authentication process.
    – user15194
    Commented Feb 25, 2016 at 10:34
  • Origin is unrelated to authentication. It is to detect cross site only. And please add the information what your question is really about to the question and not only to some comments. Commented Feb 25, 2016 at 10:46
  • @SteffenUllrich the question was intended to defense in general, not to the specific scenario of my concern.
    – user15194
    Commented Feb 25, 2016 at 12:23

2 Answers 2


Checking the Origin header prevents a WebSocket from being used by another website that the user is also visiting (e.g. to extract data).

As per the link:

WebSockets are not restrained by the same-origin policy

This is because the protocol upgrade request will have access to the user's cookies, so if you're not checking the origin the request could have been made from example.com and not your site example.net.

e.g. if you have a WebSocket service that returns some private data, you do not want a malicious site that the user has open from reading data from yours because the user is logged in.

It has nothing to do with stopping another website from leeching content from your website - if they wanted to do this they would simply set up a connection to your socket web service from their back-end, where they can set whatever Origin header they want. Checking the Origin header will stop this for authenticated content because they cannot get their back-end to supply the user's authentication cookie to your web service.

They could of course register a user and then send in the authentication cookie for that using their back-end HTTP client. However, the only data they would be accessing is their own, not the end-user's. You may want to detect if certain usernames or remote IPs are pulling lots of your public content down in order to prevent use of functionality in your service that may not be user specific.

  • Question: How does checking the Origin header help security at all, if the authenticated content is protected by mechanisms of authentication cookie? It seems to me that the Origin header is easily forged and therefore useless. Commented Feb 26, 2022 at 15:34
  • 1
    Because this is a client-side attack. The attacker isn't attacking the server, they're enticing victims to follow their link where they can then attack the user's session via the browser using JavaScript. The Origin header cannot be spoofed using JavaScript as it's a forbidden header name Commented Feb 26, 2022 at 23:14

The Origin header allows you to prevent another website from exposing your websocket-service to their users.

Let's say you build a web application which consists of a relatively uninteresting HTML+Javascript client on www.example.net which receives data from your far more exciting server backend through websockets on ws.example.net.

Now someone else creates an own website www.example.com which clones your html+javascript side, but still has it connect to ws.example.net. So they benefit from your server backend by having their users leech your server capacity and your data without your permission. You don't like that.

What can you do?

All the websocket connections from the users from the other website will have Origin:example.com while those from your own website have Origin:example.net. That allows you to only accept the connections from your own visitors.

But remember that the origin-header is set by the web browser. A user might manipulate it to still connect to your service when not going through your website. Also, someone might build and distribute a non-browser application which connects to your websocket server with a faked origin-header. Checking the origin header only prevents mass-abuse through hapless internet users who are unaware they are using a backend they are not supposed to use.

  • does it benefit somehow the authentication process? I mean, if I have thousands of clients authenticating, how would it be useful?
    – user15194
    Commented Feb 25, 2016 at 10:34
  • 1
    @yzT except for rejecting those with the wrong origin-header before even looking at their credentials it doesn't.
    – Philipp
    Commented Feb 25, 2016 at 11:29
  • so the conclusion is that the Origin header really isn't useful for securing a WebSocket... Commented Feb 26, 2022 at 15:37
  • @Kid_Learning_C That depends on what you want to secure against.
    – Philipp
    Commented Feb 26, 2022 at 15:41
  • 1
    @Kid_Learning_C No, checking the origin header does not prevent DOS attacks. There are other mitigation techniques for that, but that's a topic for another question.
    – Philipp
    Commented Feb 26, 2022 at 16:43

You must log in to answer this question.