HTML and CSS Reference
privileged apps have always been open to use any network connections and must be
installed and executed by users. Native applications do not run in a web origin, so origin
rules need not apply for WebSockets formed from privileged code.
Don't Confuse the User
In the past, one way to grant network access to unprivileged code was to prompt the user to
grant selective permission to use the network when an application requested it. In theory, this
method offers a solution to the same problems. When the user grants selective permission,
the code could be allowed to make network connections when the user explicitly allowed it,
though the application would put the responsibility of knowing how the application should
behave on the user. In reality, users do not know the impact of granting permissions to code,
and most users will blithely click OK. Users just want applications to work.
Security-related prompts are typically annoying, confusing, and often ignored,
resulting in drastic consequences. The WebSocket approach denies applications from
ever opening an unmediated TCP connection; however, it offers the same capabilities as
typical networks, its security is better, and there is no user interface impact on the user
because of origin. Origin lets the receiving server deny connections instead of asking the
user to allow a connection.
Throttling New Connections
Although the origin header prevents floods of connections from being established at the
HTTP layer, there is still a potential DoS threat from floods of connections opening at
the TCP layer. Even open TCP connections carrying no data cost resources, and there is
the potential for vast numbers of clients to overwhelm a server even with connections
that the server would ultimately reject. To prevent connection overload, the WebSocket
API requires browsers to throttle opening new connections. As you saw in Chapter 2,
every call to the WebSocket constructor results in a new, open network socket. Browsers
limit the rate at which underlying TCP sockets open, which in turn prevents floods of TCP
connections from opening to hosts that will not accept them as WebSocket upgrades, and
does not unduly slow down applications that legitimately want to open one or a small
number of connections to the same host.
Headers with the “Sec-” Prefix
In the WebSocket opening handshake, there are several required HTTP headers, as
you can see in Listings 7-1 and 7-2. Some of these headers are pervasive across the web
platform, like origin, while other new headers were introduced to support WebSocket.
The new headers were carefully chosen and named to prevent abuse of AJAX APIs to
spoof WebSocket requests.
The client sends an HTTP request to the server asking to upgrade the protocol to
WebSocket. If the server supports this upgrade, it responds with the corresponding
headers. As explained in Chapter 3, some of these headers are required in order for the
upgrade to complete successfully. Servers and browsers both enforce this exchange and