Allow Only Specific/official Html5 Web Apps To Connect To A Websocket Host

is it possible to ensure, that establishing a web socket connection (via socket.io) is only possible from an 'official' (HTML5) app? The target is, that third party apps with knowl

Solution 1:

There is really no way to do this directly because of the openness of code that runs in a browser. You can require APIkeys or some such thing, but if you're using those APIkeys from a browser, they are not a secret so anyone can discover them and use them from their own app.

The most common way sites deal with this is to require user authentication on your websocket connection (can often leverage webpage user authentication that may already have been done via a cookie that is already present). This obviously requires users to have an account on your service and to login to that account. Then, if you see misuse of a particular connection, you can ban that user's credentials from the service.

This does not prevent someone from setting up a rogue server process that uses their own credentials to use your API, but if you detect potential misuse, then you at least have a mechanism for locking them out (at least temporarily until they make a new account).

---

You can also make sure your service does not accept cross-origin requests. This prevents other browser-based applications from using your API directly from the browser. It does not stop a script (running outside the browser or on a server) from using your API.

---

You can create terms of service that allow you to ban any access that is not consistent with your terms. This is really just a legal backstop if needed, but doesn't prevent purposeful misuse.

---

You can build into your API some detection of abnormal usage patterns (such as someone attempting to harvest all data from your site) that would not normally be attempted by your regular client application. This could then lead to an account being flagged that a human might look into further and decide whether to notify or ban the account. Many services like Google services have rate limiting built into the site to keep one particular connection from using more than a fair share of server resources. That path is more of server-protection or load-protection-tactic rather than a prevent-unauthorized-use feature.

---

Another technique I've seen described which is a deterrent, but not actually used myself is to embed an everchanging code into each of your legitimate web-site pages that uses your API and require that code to be sent with all API requests. This prevents the API from being used entirely on it's own without first making a web page request to fetch the code. If the code itself is not directly embedded in the page, but instead is calculated with some Javascript based on some other things embedded in the web page, then it makes it even more work for a server process to scrape the code out of a web page request. The everchanging code then has some lifetime and your server can tell when it has expired. This is not true security because an enterprising developer can work around it by making a normal web request, getting the tokens needed to then calculate the current version of the everchanging code and to do that regularly to keep their code up to date. But, it does make it enough work that it's a deterrent to the more casual hacker trying to use your API.

---

And, if you see repeated abuse from a particular source, you can also block IP ranges from your service (at the risk of accidentally blocking some legitimate users too).

Solution 2:

Conceptually such a thing is not possible. You need to send everything required to connect to the API to the client; meaning all the client code is entirely public.* With all the details necessary to connect being public, there's nowhere you could place any secrets that would distinguish "official" from "unofficial" clients. Further, when does a client stop being "official"? What if the user places a breakpoint in their browser's Javascript console and alters some code ever so slightly? How different is that from writing a conforming "unofficial" client from scratch?

Your security needs to be in the API itself, which needs to check whether a client is allowed to do a specific action or not. Attempting to base your security on confirming the authenticity of the client is bound to fail.

* Well, unless you don't make your code public and require authentication previous to downloading it. Then you could theoretically intertwine and pre-compile the code with some client-specific token. But that sounds like more trouble than it's worth and still won't really protect you from altered clients.