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? – Steffen Ullrich Feb 25 '16 at 9:39
  • @SteffenUllrich rather the latter. I'm mostly interested in how it helps during the authentication process. – Ay0 Feb 25 '16 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. – Steffen Ullrich Feb 25 '16 at 10:46
  • @SteffenUllrich the question was intended to defense in general, not to the specific scenario of my concern. – Ay0 Feb 25 '16 at 12:23

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.

| improve this answer | |

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.

| improve this answer | |
  • does it benefit somehow the authentication process? I mean, if I have thousands of clients authenticating, how would it be useful? – Ay0 Feb 25 '16 at 10:34
  • @yzT except for rejecting those with the wrong origin-header before even looking at their credentials it doesn't. – Philipp Feb 25 '16 at 11:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.