Securing secure websockets
Secure Websockets start life as a standard HTTPS request and only connect if a valid HTTPS connection can be established with the server. As a result, websockets will automatically respect any public key pinning, strict transport policies, etc, which the server sets in the response headers when the client first attempts to establish a websocket connection.
Therefore, for web browsers, it's simply a matter of providing a standard
Public-Key-Pins header. I couldn't say how it works for mobile clients. It may vary from platform-to-platform, but it wouldn't surprise me if many simply follow the same security headers as browsers.
Note though that you may not want to actually bother with public key pinning, as it seems that support for it is waning or even already gone. The trouble with public key pinning is that it is one of the only security measures that can literally lock people out of your website in a way that cannot be fixed, as has happened to businesses.
You linked to an article which discusses the fact that you cannot set request/response headers over a websocket connection. This is true, but it also doesn't change my above answer. The article is actually talking about something different, although it is a common source of misunderstanding (I ran into the same question myself when I enabled authentication on my first websocket server and client). To explain though it's important to understand the lifecycle of a websocket request:
- The client sends a standard HTTP request to the server with a special
- The server sees the header and sends a response letting the client know it accepts the request to upgrade to a new protocol
- Having been officially upgraded, the client and server both keep the original TCP connection open and send data back and forth through it directly as needed
Your article is referring to step 3 of this process. Once the websocket connection has been established, you can no longer send request or response headers because there are no longer HTTP requests being sent. Instead the client and server exchange data directly over the TCP connection in whatever format they want.
However, the initial attempt to establish the websocket connection still happens over a standard HTTP request and requires a standard HTTP request to be properly established. As a result, the browser should still respect any response headers sent back down by the websocket server when initially establishing a connection. And indeed, the server can send additional headers back down at that phase of the process.